Re: [PATCH 0/6] overlayfs + casefolding

[Amir Goldstein <amir73il@gmail.com>]

On Tue, May 20, 2025 at 4:12 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Tue, May 20, 2025 at 04:03:27PM +0200, Amir Goldstein wrote:
> > On Tue, May 20, 2025 at 2:43 PM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Tue, May 20, 2025 at 02:40:07PM +0200, Amir Goldstein wrote:
> > > > On Tue, May 20, 2025 at 2:25 PM Kent Overstreet
> > > > <kent.overstreet@linux.dev> wrote:
> > > > >
> > > > > On Tue, May 20, 2025 at 10:05:14AM +0200, Amir Goldstein wrote:
> > > > > > On Tue, May 20, 2025 at 7:16 AM Kent Overstreet
> > > > > > <kent.overstreet@linux.dev> wrote:
> > > > > > >
> > > > > > > This series allows overlayfs and casefolding to safely be used on the
> > > > > > > same filesystem by providing exclusion to ensure that overlayfs never
> > > > > > > has to deal with casefolded directories.
> > > > > > >
> > > > > > > Currently, overlayfs can't be used _at all_ if a filesystem even
> > > > > > > supports casefolding, which is really nasty for users.
> > > > > > >
> > > > > > > Components:
> > > > > > >
> > > > > > > - filesystem has to track, for each directory, "does any _descendent_
> > > > > > >   have casefolding enabled"
> > > > > > >
> > > > > > > - new inode flag to pass this to VFS layer
> > > > > > >
> > > > > > > - new dcache methods for providing refs for overlayfs, and filesystem
> > > > > > >   methods for safely clearing this flag
> > > > > > >
> > > > > > > - new superblock flag for indicating to overlayfs & dcache "filesystem
> > > > > > >   supports casefolding, it's safe to use provided new dcache methods are
> > > > > > >   used"
> > > > > > >
> > > > > >
> > > > > > I don't think that this is really needed.
> > > > > >
> > > > > > Too bad you did not ask before going through the trouble of this implementation.
> > > > > >
> > > > > > I think it is enough for overlayfs to know the THIS directory has no
> > > > > > casefolding.
> > > > >
> > > > > overlayfs works on trees, not directories...
> > > >
> > > > I know how overlayfs works...
> > > >
> > > > I've explained why I don't think that sanitizing the entire tree is needed
> > > > for creating overlayfs over a filesystem that may enable casefolding
> > > > on some of its directories.
> > >
> > > So, you want to move error checking from mount time, where we _just_
> > > did a massive API rework so that we can return errors in a way that
> > > users will actually see them - to open/lookup, where all we have are a
> > > small fixed set of error codes?
> >
> > That's one way of putting it.
> >
> > Please explain the use case.
> >
> > When is overlayfs created over a subtree that is only partially case folded?
> > Is that really so common that a mount time error justifies all the vfs
> > infrastructure involved?
>
> Amir, you've got two widely used filesystem features that conflict and
> can't be used on the same filesystem.
>
> That's _broken_.

Correct.

I am saying that IMO a smaller impact (and less user friendly) fix is more
appropriate way to deal with this problem.

>
> Users hate partitioning just for separate /boot and /home, having to
> partition for different applications is horrible. And since overlay fs
> is used under the hood by docker, and casefolding is used under the hood
> for running Windows applications, this isn't something people can
> predict in advance.

Right, I am not expecting users to partition by application,
but my question was this:

When is overlayfs created over a subtree that is only partially case-folded?

Obviously, docker would create overlayfs on parts of the fs
and smbd/cygwin could create a case folder subtree on another
part of the fs.
I just don't see a common use case when these sections overlap.

Perhaps I am wrong (please present real world use cases),
but my claim is that this case is not common enough and therefore,
a suboptimal EIO error from lookup is good enough to prevert crossing
over into the case folded zone by mistake, just as EIO on lookup is
enough to deal with the unsupported use case of modifying
overlayfs underlying layers with overlay is mounted.

BTW, it is not enough to claim that there is no case folding for the
entire subtree to allow the mount.
For overlayfs to allow d_hash()/d_compare() fs must claim that
these implementations are the default implementation in all subtree
or at least that all layers share the same implementation.

Thanks,
Amir.