Re: [PATCH 27/32] xfs: Add parent pointer ioctls

Christoph Hellwig
2024-04-16T16:54:15Z

On Tue, Apr 16, 2024 at 09:50:56AM -0700, Darrick J. Wong wrote:
> On Tue, Apr 16, 2024 at 06:47:16AM +0200, Christoph Hellwig wrote:
> > On Mon, Apr 15, 2024 at 12:40:36PM -0700, Darrick J. Wong wrote:
> > > True, libhandle is a very nice wrapper for the kernel ioctls. I wish
> > > Linux projects did that more often. But suppose you're calling the
> > > ioctls directly without libhandle and mess it up?
> >
> > The you get different inodes back. Not really any different from
> > pointing your path name based code to the wrong fs or directory,
> > is it?
>
> I suppose not. But why bother setting the fsid at all, then?

I suspect that's a leftover from IRIX where the by handle operations
weren't ioctls tied to a specific file system.

> > But as we never generate the file handles that encode the parent
> > we already never connect files to their parent directory anyway.
>
> I pondered whether or not we should encode parent info in a regular
> file's handle.

We shouldn't. It's a really a NFS thing.

> Would that result in an invalid handle if the file gets
> moved to another directory?

Yes.

> That doesn't seem to fit with the behavior
> that fds remain attached to the file even if it gets moved/deleted.

Exactly.

>
> > OTOH we should be able to optimize ->get_parent a bit with parent
> > pointers, as we can find the name in the parent directory for
> > a directory instead of doing linear scans in the parent directory.
> > (for non-directory files we currenty don't fully connect anwyay)
>
> <nod> But does exportfs actually want parent info for a nondirectory?
> There aren't any stubs or XXX/FIXME comments, and I've never heard any
> calls (at least on fsdevel) for that functionality.

It doesn't. It would avoid having disconnected dentries, but
disconnected non-directory dentries aren't really a problem.