Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | Date | Thu, 14 Sep 2000 12:24:29 -0400 (EDT) |
| |
Theodore Y. Ts'o writes: > From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
>> 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.
First of all, I give you fragments:
frag_data = 0; file_size = i_size; if(i_size_high>>31){ /* high bit marks fragment data */ frag_data = i_size_high; }else{ file_size |= (__u64)i_size_high << 32; /* frag is insignificant */ }
Second of all, you had been planning on extents. With extents, there should be no need to play around with fragments. You just use a small block size.
Third, if somebody wants UFS, they can use the UFS driver! More likely, these people should be using Reiserfs.
> 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.
Oh well. People used to gripe about ext2 being bloated compared to the early Linux filesystems. Now we are getting JFS, with its huge quad-size inodes.
> 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.
Would you give up 6, 17, 21, or 30 bits? This would chop away at the protection offered by i_generation.
Since accurate timestamps are generally useful for NFS and "make", they ought to get at least 30 bits, if not 60. (for the three) - 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/
|  |