Running xfstests on the JFS file system

Hi Shaggy,

I hope this note finds you well.  Out of curiousity, I recently
extended {kvm,gce}-xfstests[1][2] to run tests for JFS.

[1] http://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md

When I ran those tests, I noted that a lot of tests were failing:

TESTRUNID: tytso-20190624085231
KERNEL:    kernel 5.2.0-rc2-xfstests-00018-gd0191a583b08 #1083 SMP Sun Jun 23 22:24:13 EDT 2019 x86_64
CMDLINE:   -c jfs -g auto
CPUS:      2
MEM:       7680

jfs/default: 864 tests, 55 failures, 312 skipped, 4932 seconds
  Failures: generic/034 generic/039 generic/040 generic/041
    generic/056 generic/057 generic/065 generic/066 generic/073
    generic/079 generic/083 generic/090 generic/101 generic/104
    generic/106 generic/107 generic/204 generic/226 generic/258
    generic/260 generic/269 generic/288 generic/321 generic/322
    generic/325 generic/335 generic/336 generic/341 generic/342
    generic/343 generic/348 generic/376 generic/405 generic/416
    generic/424 generic/427 generic/456 generic/467 generic/475
    generic/479 generic/480 generic/481 generic/489 generic/498
    generic/502 generic/510 generic/520 generic/526 generic/527
    generic/534 generic/535 generic/537 generic/547 generic/552
    generic/557
Totals: 552 tests, 312 skipped, 55 failures, 0 errors, 4905s

Quite a number of these test failures (at least 65%) apparently are
linked to the fact that apparently JFS doesn't replay the journal in
the kernel, and requires that fsck.jfs be run to do that journal
replay.  Is that correct?  That at least appears to be my superficial
analysis, but I'm not 100% sure because when you mount a file system
which is need of a journal replay, the mount system call returns with
an EINVAL error, and so the mount program prints:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/flakey-test,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Unfortunately, there is nothing in dmesg; so it's not entirely clear
why JFS kernel code was unhappy enough to return EINVAL.  I know that
you're only supporting JFS on a best-efforts basis, but I see that
you're still sending commits to Linus, so perhaps this is something
that you might be interested in improving?

In terms of fixing the xfstests failures, I *think* what we should do
is to prefix all attempts to mount a JFS file system --- or at least
those after a deliberate attempt to simulate a power fail condition,
such as when using _dmflakey_drop_and_remount with:

     /sbin/fsck.jfs --replay_journal_only <device>

However, the following comments in the fsck.jfs man page give me
pause:

       --replay_journal_only
              Only replay the transaction log.  Do not continue with a
              full file system check if the replay fails or if the
              file system is still dirty even after a journal replay.
              In general, this option should only be used for
              debugging purposes as it could leave the file system in
              an unmountable state....

Under what conditions will fsck.jfs --replay_journal_only leave the
file system in an unmounting state?  Assuming a bug-free(tm) kernel,
and perfect hardware that never has any I/O errors or media-induced
corruptions, should "fsck.jfs --replay_journal_only" always work?
Under what conditions might it not?

Thanks,

						- Ted