[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <175676417816.2234665.1558702055638831789@noble.neil.brown.name>
Date: Tue, 02 Sep 2025 08:02:58 +1000
From: "NeilBrown" <neil@...wn.name>
To: "Amir Goldstein" <amir73il@...il.com>
Cc: "Gabriel Krisman Bertazi" <gabriel@...sman.be>,
André Almeida <andrealmeid@...lia.com>,
"Miklos Szeredi" <miklos@...redi.hu>, "Theodore Tso" <tytso@....edu>,
linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, "Alexander Viro" <viro@...iv.linux.org.uk>,
"Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>,
kernel-dev@...lia.com
Subject:
Re: [PATCH v6 9/9] ovl: Support mounting case-insensitive enabled layers
On Fri, 29 Aug 2025, Amir Goldstein wrote:
> On Fri, Aug 29, 2025 at 3:25 AM NeilBrown <neil@...wn.name> wrote:
> >
> > On Thu, 28 Aug 2025, Amir Goldstein wrote:
> > >
> > > Neil,
> > >
> > > FYI, if your future work for vfs assumes that fs will alway have the
> > > dentry hashed after create, you may want to look at:
> > >
> > > static int ovl_instantiate(struct dentry *dentry, struct inode *inode,
> > > ...
> > > /* Force lookup of new upper hardlink to find its lower */
> > > if (hardlink)
> > > d_drop(dentry);
> > >
> > > return 0;
> > > }
> > >
> > > If your assumption is not true for overlayfs, it may not be true for other fs
> > > as well. How could you verify that it is correct?
> >
> > I don't need the dentry to be hashed after the create has completed (or
> > failed).
> > I only need it to be hashed when the create starts, and ideally for the
> > duration of the creation process.
> > Several filesystems d_drop() a newly created dentry so as to trigger a
> > lookup - overlayfs is not unique.
> >
> > >
> > > I really hope that you have some opt-in strategy in mind, so those new
> > > dirops assumptions would not have to include all possible filesystems.
> >
> > Filesystems will need to opt-in to not having the parent locked. If
> > a fs still has the parent locked across operations it doesn't really
> > matter when the d_drop() happens. However I want to move all the
> > d_drop()s to the end (which is where ovl has it) to ensure there are no
> > structural issues that mean an early d_drop() is needed. e.g. Some
> > filesystems d_drop() and then d_splice_alias() and I want to add a new
> > d_splice_alias() variant that doesn't require the d_drop().
> >
>
> Do you mean revert c971e6a006175 kill d_instantiate_no_diralias()?
Something like that, yes. Details will probably end up being a bit
different.
>
> In any case, I hope that in the end the semantics of state of dentry after
> lookup/create will be more clear than they are now...
That would be nice. Not just clear, but documented would be the aim.
NeilBrown
Powered by blists - more mailing lists