[HEADS-UP] Using stored immutable file birth time for SMB File-ID

[Ralph Boehme]

On 6/26/19 8:51 PM, Christof Schmitt wrote:
> On Wed, Jun 26, 2019 at 08:08:37PM +0200, Ralph Boehme via samba-technical wrote:
>> On 6/26/19 7:59 PM, Ralph Boehme via samba-technical wrote:
>>> On 6/26/19 6:12 PM, David Disseldorp wrote:
>>>> - given that this issue is Apple client specific, is there a need for
>>>>   this new logic to be implemented outside of vfs_fruit?
>>>
>>> yes, I think our current semantics based on inodes is dumb and we need a
>>> general fix.
>>
>> an additional note: from an implementation perspective it would be ideal
>> to store the additional state in an existing xattr, instead of an
>> additional one.
>>
>> We need to fetch the state for directory enumerations and getxattr can
>> be slow, especially with fuse based filesytems which many of our
>> consumers love these days. So piggypacking this onto the existing DOS
>> xattr seemed like a clever idea.
> 
> Have you considered file systems that store the birthtime in metadata
> (no xattr)?

yes.

> It sounds like for that case we would need to add a new
> xattr for the new metadata.

See my initial mail:

> Existing VFS modules that want to take advantage of the new File-ID
> semantics, must either implement an immutable btime natively, and
> until that happens they have to call the VFS NEXT functions to get and
> set the immutable btime from vfs_default. vfs_ceph already does this,
> but vfs_gpfs needs to be updated.

Currently gpfs doesn't call VFS NEXT for the DOS attributes function.
Unfortunately adding that has a performance impact, but you have to die
one death.

Maybe GPFS has some kind of immutable creation date that could be
exposed to userspace?

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46