[Bug 207635] EXT4-fs error (device sda3): ext4_lookup:1701: inode #...: comm find: casefold flag without casefold feature; EXT4-fs (sda3): Remounting filesystem read-only

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=207635

--- Comment #8 from Joerg M. Sigle (joerg.sigle@jsigle.com) ---
Thank you all for your explanations, again.

> Casefold is an 'incompat' feature, because it changes the directory format.
> So if someone enables it (on-disk [...]), old kernels can't use the
> filesystem at all.

Might this not warrant a warning in the ext4/ext5 manpage?
E.g. similar to what is there for the "ext64" feature:

"Note that some older kernels and older versions of e2fsprogs
 will not support file systems with this ext4 feature enabled."

The current text doesn't reveal this:

"[casefold] is name-preserving on the disk, but it
 allows applications to lookup for a file in the file system
 using an encoding equivalent version of the file name."

The required minimum versions of e2fsck, tune2fs etc. might also be mentioned.


> This issue is about how the kernel treats inodes that got corrupted
> to have the casefold flag set when the user didn't actually enable the
> casefold feature. The ext4 feature flags have clear behavior for how
> unexpected flags are handled, but the inode flags don't.

I use ext2 as least common denominator for multiple OS. I use conservative
settings. And still "got caught" by a new (!) disabled (!) opt-in (!) feature,
with hits apparently coming out-of-the-blue, and left without (much of) a clue
:-)

So IMHO a system not expected to use certain bits should rather not turn the fs
to r/o because of them. Or, at least, indicate the minimum e2fsck version
needed for fixing.

These bits could, however, still be checked very systematically: by letting
tune2fs  recommend (or even call?) ext2fs whenever a user is about to enable
casefold support on a preexisting fs. Only then, these bits become really
meaningful, the admin is ready, and ext2fs is guaranteed to be sufficiently
new.

Anytime afterwards, once that feature *is* enabled - any form of checking and
reaction by the kernel would be perfectly fine and no bad surprise anymore.

Equally ok: Revelation of the problem by regular scheduled e2fsck runs, once
e2fsck has been sufficiently updated over time to recognize and handle the
problem.

Thanks again for your consideration & regards! Joerg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.