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.
