On Wed, 13 Dec 2023, Dave Chinner wrote: > On Tue, Dec 12, 2023 at 09:15:29AM -0800, Frank Filz wrote: > > > On Tue, Dec 12, 2023 at 10:10:23AM +0100, Donald Buczek wrote: > > > > On 12/12/23 06:53, Dave Chinner wrote: > > > > > > > > > So can someone please explain to me why we need to try to re-invent > > > > > a generic filehandle concept in statx when we already have a have > > > > > working and widely supported user API that provides exactly this > > > > > functionality? > > > > > > > > name_to_handle_at() is fine, but userspace could profit from being > > > > able to retrieve the filehandle together with the other metadata in a > > > > single system call. > > > > > > Can you say more? What, specifically is the application that would want > > to do > > > that, and is it really in such a hot path that it would be a user-visible > > > improveable, let aloine something that can be actually be measured? > > > > A user space NFS server like Ganesha could benefit from getting attributes > > and file handle in a single system call. > > At the cost of every other application that doesn't need those > attributes. Why do you think there would be a cost? statx only returns the attributes that it was asked for. If an application doesn't ask for STATX_HANDLE, it doesn't get STATS_HANDLE and (providing filesystems honour the flag) doesn't pay the price for generating it (which is often trivial, but may not always be). NeilBrown > That's not a good trade-off - the cost of a syscall is > tiny compared to the rest of the work that has to be done to create > a stable filehandle for an inode, even if we have a variant of > name_to_handle_at() that takes an open fd rather than a path. > > > Potentially it could also avoid some of the challenges of using > > name_to_handle_at that is a privileged operation. > > It isn't. open_by_handle_at() is privileged because it bypasses all > the path based access checking that a normal open() does. Anyone can > get a filehandle for a path from the kernel, but few can actually > use it for anything other than file uniqueness checks.... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
