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

[Theodore Y. Ts'o]

   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/