On 12/12/23 16:20, Theodore Ts'o 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? Probably not for the specific applications I mentioned (backup, mirror, accounting). These are intended to run continuously, slowly and unnoticed in the background, so they are memory and i/o throttled via cgroups anyway and one is even using sleep after so-and-so many stat calls to reduce its impact. If they could tell a directory from a snapshot, I would probably stop them from walking into snapshots. And if not, the snapshot id is all that is needed to tell a clone in a snapshot from a hardlink. So these don't really need the filehandle. In the thread it was assumed, that there are other (unspecified) applications which need the filehandle and currently use name_to_handle_at(). I though it was self-evident that a single syscall to retrieve all information atomically is better than a set of syscalls. Each additional syscall has overhead and you need to be concerned with the data changing between the calls. Userspace nfs server as an example of an application, where visible performance is more relevant, was already mentioned by someone else. Best Donald > > - Ted -- Donald Buczek buczek@xxxxxxxxxxxxx Tel: +49 30 8413 1433
