Messages in this thread | | | From | devnull@spaans ... | Date | Thu, 14 Sep 2000 12:17:35 -0400 | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
Date: Thu, 14 Sep 2000 17:12:35 +0200 (MEST) From: R.E.Wolff@BitWizard.nl (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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |