Re: [Fwd: Re: NFS-HOWTO]

["Ragnar Kjørstad" <nfs@ragnark.vestdata.no>]

On Tue, Mar 19, 2002 at 08:20:32PM +0100, Trond Myklebust wrote:
>    - Changes to the individual filesystems so that they can save and
>      retrieve the extra 96 bits (=3D=3D 32 bits * (mtime + atime + ctim=
e))
>      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]...

I think Ted was talking about doing a disk-format change for ext[23]
soon (to improve resizing support and to extend fields like timestamps
and link-counters).

For reiserfs adding more data in the on-disk metadata is perhaps less of
a problem than for other filesystems, because reiserfs can handle
multiple inode-types on the same filesystem. (Of course old kernels
would not work with the new format, so it's still not trivial).

I haven't checked xfs, jfs or any of the other filesystems.

> 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...

Filesystems that _do_ have support for 64-bit data on-disk could still
take advantage, right?=20


--=20
Ragnar Kj=F8rstad
Big Storage

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