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 - 07:39:40 EST


   From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
   Date: Wed, 13 Sep 2000 19:20:42 -0400 (EDT)

   The ext2 inode has 6 obviously free bytes, 6 that are only used
   on filesystems marked as Hurd-type, and 8 that seem to be claimed
   by competing security and EA projects. So, being wasteful, it would
   be possible to have picoseconds on all 4 time stamps. Doing mere
   milliseconds on 3 timestamps would leave us 16 bytes for security.

Obviously free to you, perhaps, but you're not the one who allocates
bits out of the ext2 inode. There are various projects that are all
trying claim bits of ext2, including folks who want to implement
fragment support, which you've conveniently edited out of your
un-official ext2 inode structure which you sent out.

There has been some talk of doubling the size of the ext2 inode, which
will of course cause some backwards compatibility problems and would
mean that you would only be able to use certain advanced features on new
or converted ext2 filesystems. However, there are enough downsides with
this that it's something of a last resort. It would make life a lot
easier for those various people doing new ext2 features from muscling
each other over space all the time.

This is why I'd much prefer a solution which uses a few bits out of
i_generation. True, it's somewhat filesystem specific; but I expect
that any solution that's going to work over multiple filesystems is
going to have at least some filesystem specific bits. And given that we
need i_generation anyway for other purposes, we might as well allow one
of the solutions to simply borrow some number of bits from i_generation.

                                                        - 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:23 EST