From: "André Almeida" <andrealmeid@igalia.com>
To: Gabriel Krisman Bertazi <gabriel@krisman.be>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>, Theodore Tso <tytso@mit.edu>,
linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
kernel-dev@igalia.com
Subject: Re: [PATCH 0/3] ovl: Enable support for casefold filesystems
Date: Wed, 9 Apr 2025 14:02:32 -0300 [thread overview]
Message-ID: <dddab8dd-6d36-4899-ae8c-d284c4c0306c@igalia.com> (raw)
In-Reply-To: <871pu1b7l5.fsf@mailhost.krisman.be>
Hi Gabriel!
Em 09/04/2025 13:52, Gabriel Krisman Bertazi escreveu:
> André Almeida <andrealmeid@igalia.com> writes:
>
>> 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.
>
> I didn't look the patches yet, but this is going to be quite tricky.
> For a start, consider the semantics when mixing volumes with different
> case settings for lower/upper/work directories. And that could be any
> setting, such as whether the directory has +F, the encoding version and
> the encoding flags (strict mode). Any mismatch will look bonkers and
> you want to forbid the mount.
>
> Consider upperdir is case-sensitive but lowerdir is not. In this case,
> I suspect the case-exact name would be hidden by the upper, but the
> inexact-case would still resolve from the lower when it shouldn't, and
> can't be raised again. If we have the other way around, the upper
> will hide more than one file from the lower and it is a matter of luck
> which file we are getting.
>
> In addition, if we have a case-insensitive on top of a case-sensitive,
> there is no way we can do the case-insensitive lookup on the lower
> without doing a sequential search across the entire directory. Then it
> is again a matter of luck which file we are getting.
>
> The issue can appear even on the same volume, since case-insensitiveness
> is actually per-directory and can be flipped when a directory is empty.
> If something like the below is possible, we are in the same situation
> again:
>
> mkdir lower/ci
> chattr +F lower/ci
> touch lower/ci/BLA
> mount -o overlay none upperdir=upper,lowerdir=lower,workdir=work merged
> rm -r merged/ci/BLA // creates a whiteout in upper
> // merged looks empty and should be allowed to drop +F
> chattr -F merged/ci
>
> So we'd also need to always forbid clearing the +F attribute and perhaps
> forbid it from ever being set on the merged directory. We also want to
> require the encoding version and flags to match.
>
Thank you for the prompt response. I agree with you, for the next
version I will implement such restrictions. I think it will be better to
start with very restrict possibilities and then slowly dropping then, if
they prove to be not problematic.
>> * 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 will then call the generic_ci_d_compare function if it's set for
>> the dentry. There are more strncmp() around ovl, but I would rather hear
>> feedback about this approach first than already implementing this around
>> the code.
>
> I'd suggest marking it as an RFC since it is not a functional
> implementation yet, IIUC.
>
Ops, you are right, I forgot to tag it as such.
>>> * Testing
>> sudo mount -t tmpfs -o casefold tmpfs mnt/
>> cd mnt/
>> mkdir dir
>> chattr +F dir
>> cd dir/
>> mkdir upper lower
>> mkdir lower/A lower/b lower/c
>> mkdir upper/a upper/b upper/d
>> mkdir merged work
>> sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work, merged
>> ls /tmp/mnt/dir/merged/
>> a b c d
>>
>> And ovl is respecting the equivalent names. `a` points to a merged dir
>> between `A` and `a`, but giving that upperdir has a lowercase `a`, this
>> is the name displayed here.
>
> Did you try fstests generic/556? It might require some work to make it
> run over ovl, but it will exercise several cases that are quite
> hard to spot.
>
>
I haven't tried, I'm not sure which directory should I point to fstests
to use for the test, the merged one?
next prev parent reply other threads:[~2025-04-09 17:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 15:00 André Almeida
2025-04-09 15:00 ` [PATCH 1/3] ovl: Make ovl_cache_entry_find support casefold André Almeida
2025-07-11 9:46 ` Amir Goldstein
2025-07-14 20:12 ` Gabriel Krisman Bertazi
2025-04-09 15:00 ` [PATCH 2/3] ovl: Make ovl_dentry_weird() accept casefold dentries André Almeida
2025-04-09 17:11 ` Amir Goldstein
2025-07-11 9:20 ` Amir Goldstein
2025-04-09 15:00 ` [PATCH 3/3] ovl: Enable support for casefold filesystems André Almeida
2025-04-09 16:52 ` [PATCH 0/3] " Gabriel Krisman Bertazi
2025-04-09 17:02 ` André Almeida [this message]
2025-04-09 17:17 ` Amir Goldstein
2025-07-10 20:54 ` André Almeida
2025-07-11 9:08 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dddab8dd-6d36-4899-ae8c-d284c4c0306c@igalia.com \
--to=andrealmeid@igalia.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=gabriel@krisman.be \
--cc=jack@suse.cz \
--cc=kernel-dev@igalia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®