On Thu, Jul 10, 2025 at 10:54 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote: > > Hi Amir, > > Sorry for my delay. > > Em 09/04/2025 14:17, Amir Goldstein escreveu: > > On Wed, Apr 9, 2025 at 5:01 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote: > >> > >> Hi all, > >> > >> We would like to support the usage of casefold filesystems with > >> overlayfs. This patchset do some of the work needed for that, but I'm > >> sure there are more places that need to be tweaked so please share your > >> feedback for this work. > >> > >> * Implementation > >> > >> The most obvious place that required change was the strncmp() inside of > >> ovl_cache_entry_find(), that I managed to convert to use d_same_name(), > > > > That's a very niche part of overlayfs where comparison of names matter. > > > > Please look very closely at ovl_lookup() and how an overlay entry stack is > > composed from several layers including the option to redirect to different names > > via redirect xattr, so there is really very much to deal with other > > than readdir. > > > > I suggest that you start with a design proposal of how you intend to tackle this > > task and what are your requirements? > > Any combination of casefold supported layers? > > > > The intended use case here is to use overlayfs as a container layer for > games. The lower layer will have the common libraries required for > games, and the upper layer will be a container for the running game, so > the game will be able to have write permission and even change the > common libraries if needed without impacting the original libraries. For > that, we would use case-folded enable ext4 mounting points. > > This use case doesn't need layers redirection, or to combine different > layers of enabled/disable case-fold. We would have just two layers, > upper and lower, both with case-fold enabled prior to mounting. If the > layers doesn't agree on the casefold flags/version/status, we can refuse > mounting it. > > To avoid complexity and corner cases, I propose to have this feature > enabled only for the layout described above: one upper and one lower > layer, with both layers with the same casefold status and to refuse > otherwise. > > The implementation would be, on top of this patchset, to create > restrictions on the mounting options if casefold is enabled in a > mounting point. > > Thoughts? > Good plan, but I don't think it is enough. First of all take a look at this patch already queued for next: https://lore.kernel.org/linux-unionfs/20250602171702.1941891-1-amir73il@xxxxxxxxx/ We will now check for ovl_dentry_casefolded() per dir on every lookup, not only at mount time, so you need to rebase your patches and adjust the logic to per-ovl-dir logic - all entries in ovl_stack need to have same casefold. The second thing is that from vfs POV, your patches do not mark the overlayfs dirs as casefolded and do not define d_compare()/d_hash() methods for overlayfs. I think this is wrong and will result in odd behavior w.r.t overlayfs dcache. I think that ovl_fill_super(), in the case where all layers are on same fs and that fs sb_has_encoding(), assign ovl sb->s_encoding = upper_sb->s_encoding and call generic_set_sb_d_ops(). As a matter of fact, I don't think we even need to restrict to all layers on same sb, just to all layers use the same sb->s_encoding and I think this will be pretty easy to implement on-the-fly. Then in ovl_lookup() when composing the overlayfs stack for ovl_inode, IFF ovl has_encoding make sure that all or none dentry on stack are ovl_dentry_casefolded() and if they are casefolded, mark also the overlay inode S_CASEFOLDED as well. Please make sure to write fstests for the new functionality. You can base you test on my WIP test for the patch that is in linux-next: https://github.com/amir73il/xfstests/commits/ovl-casefold/ Your changes are going to change the results of my test to allow lookup in a lower casefolded subdir and so will need to change test expectation and add file name case insensitive lookups to test this case. Thanks, Amir.
