Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Thu Sep 14 2000 - 11:17:35 EST


   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/



This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:24 EST