>>>>> " " == Andi Kleen <ak@suse.de> writes:
> On Thu, Sep 14, 2000 at 10:49:59AM +0200, Trond Myklebust
> wrote:
>> >>>>> " " == Albert D Cahalan <acahalan@cs.uml.edu> writes:
>>
>> > 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.
>>
>> It's probably more realistic given the time resolution on most
>> PCs. One could perhaps allow for greater resolution on those
>> filesystems that have the storage for it at the VFS level.
> You could also just keep the more finegrained mtime in core and
> when you flush the inode round it up to the next second.
That would work for ordinary (stateful) filesystems where you open it,
then read/write whatever you need then close the file.
The reason I'm sceptical to this and other in-core type solutions is
that knfsd doesn't keep files open for long: basically it opens a file
and close it upon processing of each and every request from a
client. You can therefore easily risk losing the inode between two
requests while the file is still open on the client.
If this means that you also lose part of the info in the mtime field,
then you will trigger a data cache invalidation on the client.
It's very important to avoid excessive cache invalidation if you want
stuff like mmap() to work on the client.
Cheers,
Trond
-
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:23 EST