On Tue, May 20, 2025 at 05:13:37PM +0200, Amir Goldstein wrote: > On Tue, May 20, 2025 at 4:44 PM Kent Overstreet > <kent.overstreet@xxxxxxxxx> 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. Since you were asking for use cases - docker & related are pretty widely used for deploying things that are "unwieldy" within the normal packgae manager ecosystem - and wine is case study #1 in that, where these days people want to ship a specific version of wine with applications being emulated (that's been tested with that application). But wine wants casefolding, so - hapless user deploys docker image where casefolding is enabled _but only on the subdir that holds Windows data_, not the whole image. Docker mounts the image, but then everything explodes when you try to use it with what look to the user like impenetrable IO errors. That's a bad day for someone, or more likely a lot of someones.
