Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 13 Jan 2022 09:50:44 -0800
From:   Jeremy Allison <jra@samba.org>
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "amir73il@gmail.com" <amir73il@gmail.com>,
        Lance Shelton <Lance.Shelton@hammerspace.com>,
        Richard Sharpe <Richard.Sharpe@hammerspace.com>,
        "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
        "ntfs3@lists.linux.dev" <ntfs3@lists.linux.dev>,
        "hch@infradead.org" <hch@infradead.org>,
        "almaz.alexandrovich@paragon-software.com" 
        <almaz.alexandrovich@paragon-software.com>,
        "djwong@kernel.org" <djwong@kernel.org>,
        "dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>,
        "slow@samba.org" <slow@samba.org>,
        "sfrench@samba.org" <sfrench@samba.org>
Subject: Re: [bug report] NFS: Support statx_get and statx_set ioctls
Message-ID: <YeBmdHzvSlIIwmIM@jeremy-acer>
Reply-To: Jeremy Allison <jra@samba.org>
References: <20220111074309.GA12918@kili>
 <Yd1ETmx/HCigOrzl@infradead.org>
 <CAOQ4uxg9V4Jsg3jRPnsk2AN7gPrNY8jRAc87tLvGW+TqH9OU-A@mail.gmail.com>
 <20220112174301.GB19154@magnolia>
 <CAOQ4uxh7wpxx2H6Vpm26OdigXbWCCLO1xbFapupvLCn8xOiL=w@mail.gmail.com>
 <Yd/HIYsCBPH5jPmS@jeremy-acer>
 <3cf76cc19f12f3e9da2eae7fe12e2719c8e499f8.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <3cf76cc19f12f3e9da2eae7fe12e2719c8e499f8.camel@hammerspace.com>
Precedence: bulk

On Thu, Jan 13, 2022 at 02:58:19PM +0000, Trond Myklebust wrote:
>On Wed, 2022-01-12 at 22:30 -0800, Jeremy Allison wrote:
>> On Thu, Jan 13, 2022 at 05:52:40AM +0200, Amir Goldstein wrote:
>> >
>> > To add one more terminology to the mix - when Samba needed to cope
>> > with these two terminologies they came up with itime for
>> > "instantiation time"
>> > (one may also consider it "immutable time").
>>
>> No, that's not what itime is. It's used as the basis
>> for the fileid return as MacOSX clients insist on no-reuse
>> of inode numbers when a file is deleted then re-created,
>> and ext4 will re-use the same inode.
>
>So basically it serves more or less the same purpose as the generation
>counter that most Linux filesystems use in the filehandle to provide
>similar only-once semantics?

Kind of, although we moved it recently to be
a current_time + random skew as the timestamp
resolution in ext4 just wasn't enough to get us
unique fileids.