>>>>> " " == Theodore Y Ts'o <[EMAIL PROTECTED]> writes:
> Why? i_generation is a field which is only used by the NFS
> server. As far as ext2 is concerned, it's a black box value.
> Currently, as I understand things (and you're much more the
> export on the NFS code than I am) all 32 bits of i_generation
> is used to enforce uniqueness of the NFS file handler across
> the recycling of the inode (i.e., the inode is deleted, and
> then reused for something else). Is that right?
Yes. In effect you have a 32-bit counter that serves as a guarantees
that an inode is not reused 'within a reasonable period of time'.
> If we were to steal, say, 8 bits of i_generation to provide a
> subsecond indicator of freshness of the attributes by shoving
> those 8 bits into the NFS microseconds field, this shouldn't
> cause any incompatibilities, should it? (Of couse, you would
> mask out those 8 bits for the NFS file handle generation
> algorithm, which you would only have 24 bits, which still
> should be enough for its purposes.)
> My understanding of the games played by the i_generation field
> and the NFS file handle is that it's not visiable to NFS
> clients. True, it would mean a certain amount of confusion for
> those clients that kept the filesystem mounted across a
> transition between an old 2.2.16 kernel and a reboot to a new
> kernel that interpreted the i_generation field differently, but
> that should be the only compatibility problem I can think of.
> Am I missing something?
We'd want to make an implementation that is generic and fits all
'commonly used' UNIX filesystems. That means that we don't want to
apply an ext2-specific hack at the VFS or nfsd levels. The
inode-generation field is a feature on several filesystems which
already support sub-second timestamps.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
