Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Wed Sep 13 2000 - 16:32:44 EST


>>>>> " " == Theodore Y Ts'o <tytso@MIT.EDU> 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 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:22 EST