Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2024-05-27 at 04:49 -0700, hch@xxxxxxxxxxxxx wrote:
> On Sun, May 26, 2024 at 10:32:39PM +0000, Trond Myklebust wrote:
> > I assume the reason is to give the caller a race free way to figure
> > out
> > which submount the path resolves to.
> 
> But the handle op are global to the file systems (aka super_block). 
> It
> does not matter what mount you use to access it.

Sure. However if you are providing a path argument, then presumably you
need to know which file system (aka super_block) it eventually resolves
to.

> 
> Snip random things about userland NFS servers I couldn't care less
> about..
> 

My point was that at least for that case, you are better off using a
file descriptor and not having to care about the mount id.

If your use case isn't NFS servers, then what use case are you
targeting, and how do you expect those applications to use this API?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux