DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 061692085B
Subject: Re: "(deleted)" directories
To:     "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>,
        Malahal Naineni <malahal@gmail.com>
Cc:     NeilBrown <neilb@suse.com>, Marc Eshel <eshel@us.ibm.com>,
        Benjamin Coddington <bcodding@redhat.com>,
        linux-nfs <linux-nfs@vger.kernel.org>,
        linux-nfs-owner@vger.kernel.org,
        Matt Benjamin <mbenjami@redhat.com>,
        trondmy <trondmy@hammerspace.com>
References: <CAGD+tkyTyOb-iiykQLYMoa1h5cmizbe_0M0_HS=9cQC1NDznSw@mail.gmail.com>
 <OF63D29519.B9156C69-ON8825833A.000DEE9B-8825833A.000E8123@notes.na.collabserv.com>
 <87a7mp1k9a.fsf@notabene.neil.brown.name>
 <OFEF532072.6C501ABB-ON8825833B.006B930A-8825833B.006CB5D7@notes.na.collabserv.com>
 <87sh0gz7mt.fsf@notabene.neil.brown.name>
 <CAGD+tkwz_HvBmjwQgLbftf6qU-pL75SJ6a1zq_P239eXMOUDgg@mail.gmail.com>
 <87muqoyutl.fsf@notabene.neil.brown.name>
 <CAGD+tkw5QqZet6n82NavneWK8-_uHo24muxYPj+gqrY=tbk2yA@mail.gmail.com>
 <2003075164.16045771.1541493796820.JavaMail.zimbra@desy.de>
From:   Bill Baker <Bill.Baker@Oracle.com>
Message-ID: <d4c78362-a80c-cff6-8da9-b8872fb750d5@Oracle.com>
Date:   Tue, 6 Nov 2018 13:25:14 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <2003075164.16045771.1541493796820.JavaMail.zimbra@desy.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On 11/6/18 2:43 AM, Mkrtchyan, Tigran wrote:
> 
> 
> ----- Original Message -----
>> From: "Malahal Naineni" <malahal@gmail.com>
>> To: "NeilBrown" <neilb@suse.com>
>> Cc: "Marc Eshel" <eshel@us.ibm.com>, "Benjamin Coddington" <bcodding@redhat.com>, "linux-nfs"
>> <linux-nfs@vger.kernel.org>, linux-nfs-owner@vger.kernel.org, "Matt Benjamin" <mbenjami@redhat.com>, "trondmy"
>> <trondmy@hammerspace.com>
>> 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