OK, I've done some final fixups (there was something weird with the
spelling patch that caused dgit to have heartburt) and have done a
"dgit push-source" and pushed git tree to salsa. Thanks again for
your help.
Since you are investigating using f2fs, I thought I would let you know
that there are the following test failures of the file system:
KERNEL: kernel 6.1.0-xfstests #2 SMP PREEMPT_DYNAMIC Mon Dec 12 16:09:40 EST
2022 x86_64
CMDLINE: -c f2fs/default -g auto
CPUS: 2
MEM: 7680
f2fs/default: 676 tests, 5 failures, 224 skipped, 4923 seconds
Failures: generic/050 generic/064 generic/252 generic/506 generic/563
The same test failures happen with f2fs-tools 1.14 and 1.15, so these
are not f2fs-tools regressions. These are actually fewer test
failures than I am seeing with btrfs:
btrfs/4k: 953 tests, 21 failures, 176 skipped, 12135 seconds
Failures: btrfs/006 btrfs/012 btrfs/049 btrfs/100 btrfs/162 btrfs/163
btrfs/184 btrfs/192 btrfs/196 btrfs/197 btrfs/218 btrfs/219 btrfs/235
btrfs/254 btrfs/277 btrfs/291 generic/455 generic/457
Flaky: btrfs/028: 40% (2/5) generic/475: 60% (3/5)
shared/298: 20% (1/5)
.... although it's worse than the ext4/4k and xfs/4k test results
(which tests 100% green).
If you are curious about exactly what the test failures are, just
checkout the xfstests-dev repo, and then look at the first few lines
of the test script, for example:
<tytso@cwcc> {/usr/projects/xfstests-bld/build-64} (master)
1079% head fstests-bld/xfstests-dev/tests/generic/050
#! /bin/bash
# SPDX-License-Identifier: GPL-2.0
# Copyright (c) 2009 Christoph Hellwig.
#
# FS QA Test No. 050
#
# Check out various mount/remount/unmount scenarious on a read-only blockdev.
#
seqfull=$0
. ./common/preamble
(Which is a bit relevant to this original bug report, which was purely
accidental, and perhaps a bit of synchronicity.)
On Tue, Dec 13, 2022 at 11:53:53PM +0300, Michael Tokarev wrote:
>
> (and now this has absolutely nothing to do with #1025791 anyway.. ;))
Heh.
Going back to this bug, I'm pretty sure it's not going to be an easy
fix, unless you want to take over upstream f2fs-tools. Which if you
ask the f2fs-tools maintainers, they might actually be willing to
delegate; you never know until you ask. (As an aside, that's how I
got involved with ext2/ext3/ext4. Originally ext2 userspace tools
were a modified version of the minix userspace tools, and I decided I
could do better. So after rewriting it from scratch, creating a real
library interface that could actually have a stable shared library
ABI, and using test driven development, I was able to speed up e2fsck
by a factor of 10 or so. So if you're interested in getting involved
with file system development.... :-)
Failing that, probably the best approach is a quick patch, which could
either be maintained in the Debian packaging, or perhaps we can get it
upstream, might be to teach fsck.f2fs check to see if the open of the
block device is failing with EBUSY, and if the -a or -p option was
passed to fsck.f2fs, to print a warning message that running fsck on
boot is not supported, and then exit with a status code of 0.
This is a moral equivalent of what xfs and btrfs is doing. (See the
shell script found in /sbin/fsck.xfs and /sbin/fsck.btrfs.) It won't
allow f2fs to check a mounted file system, but at least it will clean
up the boot failures.
Cheers,
- Ted
