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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:24 EST