Eric Biggers <ebiggers@xxxxxxxxxx> writes: > On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote: >> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> > index 6633b20224d5..0288bedf46e1 100644 >> > --- a/fs/ext4/super.c >> > +++ b/fs/ext4/super.c >> > @@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) >> > goto failed_mount4; >> > } >> > >> > -#ifdef CONFIG_UNICODE >> > - if (sb->s_encoding) >> > - sb->s_d_op = &ext4_dentry_ops; >> > -#endif >> >> This change has the side-effect of removing the capability of the root >> directory from being case-insensitive. It is not a backward >> incompatible change because there is no way to make the root directory >> CI at the moment (it is never empty). But this restriction seems >> artificial. Is there a real reason to prevent the root inode from being >> case-insensitive? >> > > The problem is that the "lost+found" directory is special in that e2fsck needs > to be able to find it. > > That's the reason why ext4 doesn't allow the root directory to be encrypted. > (And encrypting the root directory isn't really useful anyway, since if the goal > is to encrypt a whole filesystem with one key, dm-crypt is a better solution.) > > Casefolding is a bit less problematic than encryption. But it still doesn't > entirely work, as e.g. if you name the directory "LOST+FOUND" instead (the > directory is casefolded after all...), then e2fsck can't find it. > > Unless there's a real use case for the root directory being casefolded and > people are willing to fix e2fsck, I think we should just make ext4 return an > error when setting the casefold flag on the root directory, like it does when > trying to enable encryption on the root directory. I don't have a use case where I need a root directory to be CI. In fact, when I first implemented CI, I did want to block the root directory from being made CI, just to prevent people from doing "chattr +F /" and complaining afterwards when /usr/lib breaks. My concern with the curent patch was whether this side-effect was considered, but I'm happy with either semantics. -- Gabriel Krisman Bertazi
