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

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

 



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.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux