[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
   From: "Albert D. Cahalan" <>
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.031 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site