Subject: RE: file_id

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 2 Dec 2002 08:16:30 -0800

> But your snapshot image must have a different fsid, right?

No, it isn't.  We make the all of the snapshots for a given 
directory visible under a .snapshot sub-directory of that 
original directory.  

In the past, that was part of the same fs, because v2/v3 didn't
really give you any choice.  With V4 you have a choice, but so far
we've kept to the v2/v3 handling of this, partly due to inertia,
and partly because some clients aren't able to do the automatic 
nested mounts. 

> Otherwise I
> think you're in violation of the spec, which requires the fileid to be
> unique within a "file system."

Probably.  We could address this through a different fsid or we could
use the top 32 bits of the v4 file-id as a shapshot-id.  This would 
keep within the bounds of the spec and for 32-bit clients would allow
them to use the low-order 32 bits and work the same as v2/v3, with a
flawed uniqueness that experience shows is not horribly troublesome.

---

From: Trond Myklebust <[email-masked]>
Date: 02 Dec 2002 18:16:33 +0100

>>>>> " " == Dave Noveck <Noveck> writes:

    >> Otherwise I think you're in violation of the spec, which
    >> requires the fileid to be unique within a "file system."

     > Probably.  We could address this through a different fsid or we
     > could use the top 32 bits of the v4 file-id as a shapshot-id.
     > This would keep within the bounds of the spec and for 32-bit
     > clients would allow them to use the low-order 32 bits and work
     > the same as v2/v3, with a flawed uniqueness that experience
     > shows is not horribly troublesome.

Given the current wording in the NFSv4 spec, it is reasonable for a
client to attempt to share data caches between files that have the
same file id. Doing so is actually mandatory if you wish to maintain
local data cache consistency against those servers that have not set
the 'unique_handles' attribute.

The same problem exists in v2 and v3.

Cheers,
  Trond