Messages in this thread |  | | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | Date | Fri, 15 Sep 2000 01:06:24 +0200 (MEST) | From | (Rogier Wolff) |
| |
Theodore Y. Ts'o wrote: > 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.
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.
-- ** R.E.Wolff@BitWizard.nl ** 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |