On 11/6/18 2:43 AM, Mkrtchyan, Tigran wrote:
----- Original Message -----
From: "Malahal Naineni" <malahal@xxxxxxxxx>
To: "NeilBrown" <neilb@xxxxxxxx>
Cc: "Marc Eshel" <eshel@xxxxxxxxxx>, "Benjamin Coddington" <bcodding@xxxxxxxxxx>, "linux-nfs"
<linux-nfs@xxxxxxxxxxxxxxx>, linux-nfs-owner@xxxxxxxxxxxxxxx, "Matt Benjamin" <mbenjami@xxxxxxxxxx>, "trondmy"
<trondmy@xxxxxxxxxxxxxxx>
Sent: Monday, November 5, 2018 8:40:16 AM
Subject: Re: "(deleted)" directories
My reading of section 10.3.4 of RFC7530 suggests that the client should
generally compare fsid and fileid to see if two different filehandles refer to
the same object or not.
Section 10.3.4 is for files only correct? The issue here is for
directories. Also, Trond clearly pointed that Linux breaks section
10.3.4 from his email stating "We treat always different filehandles
as if they refer to different
files. It has long been the case that snapshots from several vendors
are encoded to look like the same file (same fileid + same fsid) and
differing only by filehandle. If we were to try to consolidate those
inodes we would end up corrupting application data."
We don't respect either NFSv3 or NFSv4 RFCs in this regard!
In general, you are right. The spec is our source of truth. However,
I wouldn't rely on any word in the rfc if it wasn't implemented and
tested by various client and server implementations (this is IETF requirement!).
That's why we run multiple bake-a-thons and connectathons. Moreover,
from my experience of having outsider server implementation I can say,
that even if desired change end-up in upstream kernel, there are clients
around that don't support that functionality and will force you to solve
have a solutionin the server side.
BTW, at the one of the connectathons, Bill Baker from Oracle was telling
about migration implementation on Solaris server. And one of the issues
that thy suffer from was that file handles was in host native format and
they had a problems in migration from SPARC to x64. I am supersized, that
you run into the same issue.
Yeah, though that is just an error in implementation. ZFS stores
it's persistent data in network byte order so that the a filesystem
can be imported on machines with different byte orders. +1 for the
ZFS guys, but sadly the NFS server failed to xdr encode the file
handle need to enable FH portability between architectures. -1 for
the (Solaris) NFS guys. Fixed for 4.1 file handles, though.
<snip>
--
Bill Baker, Oracle Linux NFS development
