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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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_. 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.
