Message-ID: <CAOQ4uxjHiorTwddK98mb60VOY8zNqnyWvW=+Uz-Sn6-Sm3PUfQ@mail.gmail.com>
Date: Tue, 20 May 2025 17:13:37 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	Miklos Szeredi <miklos@...redi.hu>, Alexander Viro <viro@...iv.linux.org.uk>, 
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH 0/6] overlayfs + casefolding

On Tue, May 20, 2025 at 4:44 PM Kent Overstreet
<kent.overstreet@...ux.dev> wrote:
>
> On Tue, May 20, 2025 at 04:33:14PM +0200, Amir Goldstein wrote:
> > On Tue, May 20, 2025 at 4:12 PM Kent Overstreet
> > > 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.
>
> Less user friendly is an understatement.
>
> Obscure errors that only get reported via overloaded standard error
> codes is a massive problem today, for _developers_ - have you never had
> a day of swearing over trying to track down where in a massive subsystem
> an -EINVAL is coming from?
>
> It's even worse for end users that don't know to check the dmesg log.
>
> And I support my code, so these would turn into bug reports coming
> across my desk - no thanks; I already get enough weird shit from other
> subsystems that I have to look at and at least triage.
>
> > > 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.
>
> Today, you cannot user docker and casefolding on _different parts of_
> the same filesystem.
>
> So yees, today users do have to partition by application, or only use
> one feature or the other.
>

Didn't say there was no problem.

Argued that your fix is a big gun and not worth the added complexity.

Let's see what Miklos thinks.

> This isn't about allowing casefolding and overlayfs to fix on the same
> subtree, that would be a bigger project.
>
> > 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.
>

Nevermind. Misread patch 6.

Thanks,
Amir.

Powered by blists - more mailing lists