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

[Michael Tokarev]

12.12.2022 05:23, Theodore Ts'o wrote:
> On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote:
..
>> 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 see.

FWIW, I too prefer root fs to be read-only 99% of the time (I only
remount it rw when installing/upgrading something, usually following
by a reboot or at least restart the services who are using old libraries
still, and remount-ro again).  So my usage is quite similar to android's :)

And here, I decided to use f2fs not on a desktop, but on a special "server"
which runs either out of emmc flash or an sd card (or an usb flash device).
It is not a regular ssd or nvme media, it is much more restricted, slow
and less wear-resistant than a regular ssd. I used ext4fs there before,
but it *smells* f2fs is better suited for the task. The "servers" aren't
really servers per se, it's more routers with additional functions. One
of them is running an Intel Celeron N3050 CPU for example, out of a 8Gb
CF card on top of SDHCI interface. Cheap, and, most importantly, cold
and dust-free, and does much more than a usual "router" box.  Maybe
f2fs can also be used on stuff like Raspberry PI, on its internal EMMC
or CF storage, too, - again, it *looks* like f2fs should be a good
candidate for the task.

> 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.

..which is not something the upstream is interested in, I see.

..
> 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.

I pushed "mjt" branch yesterday to the repository (without pristine-tar
and upstream pieces so far) which updates f2fs to 1.15 and adds minor
cleanups to d/rules. Please take a look.

> 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).

This is a known issue. I've faced it a few times myself, though in
my case I didn't want to add more work for ftp-masters and tried to
avoid soname bump. In one of my famous cases, the upstream just
didn't understand how soname/soversion works and always bumped
soname on package version bump - thinking it's cool to have the
same version for the library as the package, and all my attempts
to teach them to use proper versioning (there were many) failed.
So in Debian I patched the source on every upload, to keep the
same libiscsi.so.7 (I picked it up at 7) as before.  (And  yes,
that package has many other issues).

So, let's process 1.15. I don't really care much about the lack
of shared library at this time.  Please take a look.  I'm not the
first-day Debian developer, but maybe there's something specific
to this package or your habits which I didn't think about.

Thanks!

/mjt