Messages in this thread | | | From | devnull@spaans ... | Date | Thu, 14 Sep 2000 08:39:40 -0400 | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
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/
| |