[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
   Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST)
From: Trond Myklebust <>

You might be able to steal a couple of bytes and then rewrite ext2fs
to mask those out from the 'i_generation' field, but it would mean that
you could no longer boot your old 2.2.16 kernel without trouble on
existing clients.

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?

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?

- Ted
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.024 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site