lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
Date
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/

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