On Fri, Jun 29, 2001 at 08:01:55AM -0700, Lever, Charles wrote:
Fs-independent and fs-private parts are allocated separately.
On systems
with VNODE style interface So I'm not sure what are you
talking about.
actually, they're not.
the fs-private implementations on these systems
Fs-independent and fs-private parts are allocated separately.
On systems
with VNODE style interface So I'm not sure what are you
talking about.
actually, they're not.
the fs-private implementations on these systems allocate the
in-core vnode struct, and usually allocate the private area
On Fri, 29 Jun 2001, Lever, Charles wrote:
the fs-private implementations on these systems allocate the
in-core vnode struct, and usually allocate the private area
right off the end of the fs-independent part of the vnode.
then they plant a pointer in the vnode to the fs-private area.
On Thursday 28 June 2001 07:39, Alexander Viro wrote:
BTW, cost of extra dereferncing is trivial - when we access ext2-specific
part of inode we usually
a) do it more than once in a given function
b) access a lot of stuff outside of struct inode.
It's not the only cost:
- The
On Thursday 28 June 2001 03:48, Alexander Viro wrote:
On Thu, 28 Jun 2001, Daniel Phillips wrote:
Advantages: no extra memory use, no indirection, no memory allocation
overhead.
An advantage you overlooked: clean up fs.h so it doesn't have to include
every filesystem in the known
If we're going to do this for a major filesystem, then I'd really just
rather see this being done generically during 2.5.x, making u be a
pointer only, and having the generic iput() just always free the dang
thing.
Linus
-
To unsubscribe from this list: send the line
On Wed, 27 Jun 2001, Ben LaHaise wrote:
On Wed, 27 Jun 2001, Linus Torvalds wrote:
If we're going to do this for a major filesystem, then I'd really just
rather see this being done generically during 2.5.x, making u be a
pointer only, and having the generic iput() just always free the
On Wed, 27 Jun 2001, Ben LaHaise wrote:
Are you certain that adding yet another level of pointer indirection here
is a good idea? The whole cache miss and indirection issue is exactly why
almost all systems in the world make use of a VNODE style interface.
Ben, mind looking into
On Wed, 27 Jun 2001, Linus Torvalds wrote:
and then when ext2 calls down to the generic VFS layer it just passes
ext2_inode-inode
down, and when it gets a struct inode * it uses inode_to_ext2() to
convert it to an ext2 inode pointer.
This is what the struct list_head thing
On Wed, 27 Jun 2001, Alexander Viro wrote:
We get inode initilization (generic parts) spread all over the place and
sooner or later it's going to bite us, for one thing.
I don't really think so. The struct inode has become less and less
important as far as the VFS layer is concerned, and
At 22:43 27/06/2001, Alexander Viro wrote:
On Wed, 27 Jun 2001, Linus Torvalds wrote:
and then when ext2 calls down to the generic VFS layer it just passes
ext2_inode-inode
down, and when it gets a struct inode * it uses inode_to_ext2() to
convert it to an ext2 inode pointer.
On Wednesday 27 June 2001 23:22, Linus Torvalds wrote:
we could _easily_ have the setup
struct ext2_inode {
struct inode inode; /* Generic fields */
specific-ext2 struct; /* specific fields */
};
and then when ext2 calls down to the generic
On Thu, 28 Jun 2001, Daniel Phillips wrote:
Advantages: no extra memory use, no indirection, no memory allocation
overhead.
An advantage you overlooked: clean up fs.h so it doesn't have to include
every filesystem in the known universe.
All of this also applies to struct
On Wed, 27 Jun 2001, Linus Torvalds wrote:
On Wed, 27 Jun 2001, Alexander Viro wrote:
We get inode initilization (generic parts) spread all over the place and
sooner or later it's going to bite us, for one thing.
I don't really think so. The struct inode has become less and less
On Thu, 28 Jun 2001, Andrew Morton wrote:
So the rule should be: if your private inode info is larger
than ext2's, you should allocate it separately.
Wrong. There is /proc. There is devfs or its equivalents. There are
pipes and sockets.
bloated inodes are OK since ext2 is all that matters
== Alexander Viro [EMAIL PROTECTED] writes:
Trond, could you review the patch below? I believe that it's
OK
wrt races around iget(), but I'd appreciate if you take a look
at it.
+ NFS_CACHEINV(inode);
+ /* Why so? Because we want revalidate for
On Mon, 25 Jun 2001, Trond Myklebust wrote:
As I said, the patch looks good, and the races are gone. The only
question I have is about the above section in nfs_fhget(). AFAICS the
NFS_CACHEINV() you've inserted here will get clobbered by the
nfs_refresh_inode() below it.
Erm... Sorry -
On Mon, 25 Jun 2001, Trond Myklebust wrote:
== Alexander Viro [EMAIL PROTECTED] writes:
Fine. I've moved call of nfs_refresh_inode() into both
branches, expanded it in the got the new inode, need to fill
it one and removed the redundant stuff there.
Another
Trond, could you review the patch below? I believe that it's OK
wrt races around iget(), but I'd appreciate if you take a look at it.
Effect on sizeof(struct inode): 464 bytes - 384 bytes. On K7 it
means 10 inodes per page instead of 7...
diff -urN S6-pre5/fs/nfs/flushd.c
At 08:00 22/06/2001, Alexander Viro wrote:
[snip]
diff -urN S6-pre5/include/linux/nfs_fs.h S6-pre5-NFS/include/linux/nfs_fs.h
--- S6-pre5/include/linux/nfs_fs.h Sat Jun 16 15:53:57 2001
+++ S6-pre5-NFS/include/linux/nfs_fs.h Fri Jun 22 00:21:50 2001
@@ -63,39 +63,44 @@
*/
#define
At 09:03 22/06/2001, Alexander Viro wrote:
At 08:00 22/06/2001, Alexander Viro wrote:
[snip]
diff -urN S6-pre5/include/linux/nfs_fs.h S6-pre5-NFS/include/linux/nfs_fs.h
--- S6-pre5/include/linux/nfs_fs.h Sat Jun 16 15:53:57 2001
+++ S6-pre5-NFS/include/linux/nfs_fs.h Fri Jun 22 00:21:50
On Fri, 22 Jun 2001, Anton Altaparmakov wrote:
-#define NFS_FH(inode) ((inode)-u.nfs_i.fh)
[snip]
+#define NFS_FH(inode) (NFS_I(inode)-fh)
Al,
Just as a matter of interest: why do you define NFS_I as a static inline
function while you leave NFS_FS as
22 matches
Mail list logo
