Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee
Theodore Y. Ts'o wrote: >Date: Thu, 14 Sep 2000 15:09:35 +0200 (CEST) >From: Trond Myklebust <[EMAIL PROTECTED]> > >Would it perhaps make sense to use one of these last 'free' fields >as a pointer to an 'inode entension'? >If you still want ext2fs to be able to accommodate new projects and >ideas, then it seems that being able to extend the inode is a >desirable feature, but perhaps this overlaps with the apparent plans >for adding resource forks? > > For stuff that's not commonly used, perhaps. The problem is that you > take a speed hit when you have to seek somewhere else to get at the > inode extension. So for something which is going to have to be > referenced for every stat() or getattr() operation, there are a real > performance issues with doing something like that. The "right" way to do this is to have a "this spot is in use, but you don't understand it" indication for an inode (*). The "expansion ptr" can then normally point to the directly following inode, but also somewhere completely different. So a "new" system would allocate a new inode in the directly following spot. But when a "new" system would need the extension part on an old filesystem, it would allocate the nearest inode and point the extension ptr there. Roger. (*) Actually the kernel only needs the "it's in use" part. fsck needs to know what it means or to properly ignore it -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee
Date: Thu, 14 Sep 2000 17:12:35 +0200 (MEST) From: [EMAIL PROTECTED] (Rogier Wolff) The "right" way to do this is to have a "this spot is in use, but you don't understand it" indication for an inode (*). The "expansion ptr" can then normally point to the directly following inode, but also somewhere completely different. So a "new" system would allocate a new inode in the directly following spot. But when a "new" system would need the extension part on an old filesystem, it would allocate the nearest inode and point the extension ptr there. Storing the excess data in the inode table is one way to do it. But if every single inode is going to need the extra data, you've effectively halved the size of the inode table, and running out of inodes becomes a serious concern. If we really want to store more data, in the long run it'll probably be a lot faster to simply double the inode size, and write an off-line program which can move datablocks out of the way and then double the size of the inode table. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee
Theodore Y. Ts'o wrote: >Date: Thu, 14 Sep 2000 17:12:35 +0200 (MEST) >From: [EMAIL PROTECTED] (Rogier Wolff) > >The "right" way to do this is to have a "this spot is in use, but you >don't understand it" indication for an inode (*). The "expansion ptr" >can then normally point to the directly following inode, but also >somewhere completely different. > >So a "new" system would allocate a new inode in the directly following >spot. But when a "new" system would need the extension part on an old >filesystem, it would allocate the nearest inode and point the >extension ptr there. > > Storing the excess data in the inode table is one way to do it. But if > every single inode is going to need the extra data, you've effectively > halved the size of the inode table, and running out of inodes becomes a > serious concern. > > If we really want to store more data, in the long run it'll probably be > a lot faster to simply double the inode size, and write an off-line > program which can move datablocks out of the way and then double the > size of the inode table. My suggestion is indeed effectivly (almost) doubling the inode size. However, it provides an upgrade path, where you can double-boot with a kernel that DOESN"T know about the inodes. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee
Ted writes: >Trond Myklebust writes: >Would it perhaps make sense to use one of these last 'free' fields >as a pointer to an 'inode entension'? >If you still want ext2fs to be able to accommodate new projects and >ideas, then it seems that being able to extend the inode is a >desirable feature, but perhaps this overlaps with the apparent plans >for adding resource forks? > > For stuff that's not commonly used, perhaps. The problem is that you > take a speed hit when you have to seek somewhere else to get at the > inode extension. So for something which is going to have to be > referenced for every stat() or getattr() operation, there are a real > performance issues with doing something like that. Note that there is already a patch for extended attributes for ext2. These EAs are used for ACL support, but can be used for a variety of other extensions to ext2. As Ted indicates, the EAs are stored in another block, so it will reduce performance if the block is not already in memory. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS locking bug -- limited mtime resolution means nfs_lock() doesnot provide coherency guarantee
Date: Fri, 15 Sep 2000 01:06:24 +0200 (MEST) From: [EMAIL PROTECTED] (Rogier Wolff) My suggestion is indeed effectivly (almost) doubling the inode size. However, it provides an upgrade path, where you can double-boot with a kernel that DOESN"T know about the inodes. The 2.2 kernels already compute EXT2_INODE_SIZE based on a value in the superblock. So an old kernel will be able to deal correctly if we double the size of the inodes. Credit me with at least *some* foresight. :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
