Re: [Fwd: Re: NFS-HOWTO]

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Trond Myklebust <trond.myklebust@fys.uio.no> writes:

    >> Is it the inode number, or some field within the inode?  *This
    >> was supposedly a 2.5 fix item; the issue is that mtime does not
    >> have a granularity finer than one second.  What subsystem does
    >> the fix go into?  The VFS layer?  Has there been any work done
    >> on it?

     > Neil was talking about fixing this in 2.5.x (it is after all a
     > server issue). The problem is that several filesystems
     > (i.e. most notably ext2/ext3) don't have the space in their
     > on-disk inodes for <1s time resolution.  There are some ideas
     > floating around on how to get around this, but I do not believe
     > that concensus has yet been achieved...

Perhaps I should expand a little on this. The changes are twofold:

   - Change the VFS structures to support 64-bit (a|c|m)time values.
     This is not really a big deal, and nothing is stopping us from
     doing it today...

   - Changes to the individual filesystems so that they can save and
     retrieve the extra 96 bits (== 32 bits * (mtime + atime + ctime))
     as part of the on-disk metadata.
     This is non-trivial, since a lot of these filesystems have not
     got much padding left in their inodes (particularly once acls
     etc. have grabbed their share of real-estate). Even finding 32
     free bits is a real problem for ext[23]...

One solution might be to only keep the full 64-bit data in the VFS
inode cache, and to zero the low 32-bits whenever we have to reload
the metadata from the disk.
That means that each time the file falls out of cache, then the mtime
would appear to change on the client (which might then proceed to
invalidate its data cache). Not entirely satisfactory, but probably
better than nothing...

Cheers,
  Trond

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs