[Filesystems-devel] Bug#1025791: fsck.f2fs is unable to check mounted FS

[Theodore Ts'o]

On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote:
> 
> Hmm.  I'm a bit afraid it will be similar to my experience with samba.
> I come across a (data corruption) bug, discovered it's been fixed upstream
> a few years ago, tried to push the fix to debian, and ended up becoming a
> single maintainer of samba package in debian, and basically repackaging
> everything (because the package has been maintained in "rob Beter to pay
> Paul" or "random tinkering at the margins" mode for a few years).
> 
> I don't mind updating f2fs to current version in debian.  It does not seem
> to have this particular issue fixed though.

Yeah, I'm not surprised.  The f2fs file system was engineered
primarily for Android, and I'm not aware of a lot of people trying to
use f2fs as a root file system on a Linux desktop or server.  And
Android has a read-only root file system (which uses dm-verity to
cryptographically guarantee that it can't be modified), and so the
data partition can be fsck'ed before it is mounted.

So this is not likely to be something which would be fixed by the f2fs
upstream.  That's not something that they are interested in, since
their primary focus has always been for Android.

I've taken a quick look at the f2fs-tools sources, and fixing it to
support allow fsck.f2fs to operate on a mounted file system is going
to require massive surgery.  The short version is you can tell that
f2fs was written originally by firmware engineers from Samsung.

The software abstractions are utterly lacking (libf2fs communicates
with the application binary using the global variable "c", of type
struct f2fs_configuration).  The block device is opened in
get_device_info(i), with the block device name passed in
c.devices[i].path.

For e2fsprogs, the logic to determine whether the block device is
mounted, and whether it is mounted as the root device can be found in
lib/ext2fs/is_mounted.c, and the logic to decide whether it is safe to
open the block device read-only is in e2fsck/unix.c (search for code
involving EXT2_MF_ISROOT and EXT2_MF_READONLY).

There is no easy or clean way I can see to shoehorn this logic into
f2fs-tools.  If were going to tackle it, the very first thing I would
do is completely restructure libf2fs so it has a clean interface, and
then add silly things like regression tests.  Basically, the code
needs to be rototilled and rewritten almost from scratch.  Take a look
at libext2fs, which has had a stable API for multiple decades, and
then look at libf2fs, and weep.

So probably the best you can do to address this bug is to prevent the
boot up errors, by doing something like /sbin/fsck.xfs and
/sbin/fsck.btrfs.  Unless, that is, you want work with upstream to do
some pretty major surgery to f2fs-tools (whether it's done in a super
ugly way, or by first restructing the code so it has some clean
abstractions).


> (I don't remember how to join a group in whatever debian development system
> is in use there, - it was alioth before, now it seems to be just the
> mailing list part of it).

The filesystems group is pretty informal.  There is the mailing list
on lists.alioth.debian.org, and the git tree on salsa.debian.org is
writable to any DD; we're not doing any group access control.  (We
could have, but file system packages are set up with the Salsa default
which is that they are located the top-level Debian folder -- and
changing the access requires moving the gitlab project, as I
understand things.)

The maintainer is set to filesystems-devel at lists.alioth.debian.org,
and the uploaders are the folks who are primarily working on the
package.  For f2fs-tools, it's Vincent cheng (who hasn't done an
upload since 2018), and me (and my last upload was in January 2021).
I have tried to do things like clean up the debian/rules file, and
keep things up to date with Debian standards.

Probably the only place where the package is a bit unclean is that
upstream *regularly* breaks the ABI, which means that we effectively
had to bump the package version every single upstream release.
Because the ABI is completely unstable, the normal Debian rationale
for using shared library breaks down (at every single package upload,
we end up breaking the ABI, which means any packages depending on the
shared library ends up using the old, stale shared library anyway).
And I got tired of ftpmasters taking 6-9 months to process an upload
since there was always a new binary package (from the shared library
bump --- EVERY SINGLE D*MNED TIME).

Besides, the only dependency on libf2fs-tools is android-sdk packages,
which is based on an ancient Android SDK (25, and 28, where Android
SDK 28 EOL'ed in January 2022), so it's kind of hopeless from a
security perspective *anyway*, and anyone seriously doing Android
development is going to be using AOSP git repos.

Anyway, this is technically a Debian policy violation, but I really
haven't been able to bring myself to care, since it really doesn't
make any practical difference from security perspective in the Real
World.  Still, the ftpmaster lag is not quite so terrible as it used
to be, and if you decide to take over the package, you should be the
one decide whether you want to deal with a full ftpmaster review
taking potentially weeks or months at every upstream bump.

      		   	    	      	    - Ted