Re: [GIT PULL] vboxsf fixes for 5.14-1

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Jul 16, 2021 at 11:07:29AM -0700, Linus Torvalds wrote:
> 
> The argument that "it's already in a much better state than the old
> ntfs driver" may not be a very strong technical argument (not because
> of any Paragon problems - just because the old ntfs driver is not
> great), but it _is_ a fairly strong argument for merging the new one
> from Paragon.

I'm not 100% sure that "it's better than the old driver", actually.
Konstantin has not been responding to Darrick and my questions about
what sort of QA and testing they were doing.

So over the weekend, I decided to take efforts into my own hands, and
made the relatively simple changes to fstests needed to add support
for ntfs and ntfs3 file systems.  The results show that the number
fstests failures in ntfs3 is 23% *more* than ntfs.  This includes a
potential deadlock bug, and generic/475 reliably livelocking.  Ntfs3
is also currently not container compatible, because it's not properly
handling user namespaces.

For more details, please see [1] and [2] for the complete set of test
artifacts.

[1] https://www.kernel.org/pub/linux/kernel/people/tytso/fstests-results/results-ntfs-2021-08-02.tar.xz
[2] https://www.kernel.org/pub/linux/kernel/people/tytso/fstests-results/results-ntfs3-2021-08-03.tar.xz

> And I don't think there has been any huge _complaints_ about the code,
> and I don't think there's been any sign that being outside the kernel
> helps.

Historically, the file system community at large have pushed for a
fairly high bar before a file system is merged into the kernel,
because there was a concern that once a file system got dumped into
fs/ if the maintainers weren't going to commit to continuous
improvement of their file system --- the only leverage we might have
is what effectively amounts to "hazing" to make sure that the
propsective maintainers would actually be serious about continuing to
work on the file system.

One argument for why this should be the case is that unlike a dodgy
driver that "just" causes the kernel to crash, if data ends up getting
corrupted, simply rebooting won't recover the user's data.  And once a
file system is added to mainline, it's a lot harder to remove it if it
turns out to be buggy as all h*ck. 

It's not clear this has been an effective strategy.  And there are
other ways we could handle an abandonware file system --- we could
liberally festoon its Kconfig with warnings and printk "DANGER WILL
ROBINSON" messages when someone attempts to use a dodgy file system in
mainline.  But I think whatever rationale we give for accepting --- or
holding off --- on ntfs3, we should also think about how we should be
handling requests from other file systems such as bcachefs, reiserfs4,
tux3, etc.

Maybe this should be a maintainers summit discussion topic?  I
dunno....

					- Ted

P.S.  Here is the summary of the test results of running ntfs and
ntfs3 on 5.14-rc2, with the latest ntfs3 patches applied.  Note that
for ntfs3, I had to manually exclude generic/475, since running that
test will cause the kernel to lock up and prevent the rest of the
tesets from running.  So that's really 68 fstests failures for ntfs3,
versus 55 fstests failures for ntfs.

And it's really not the absolute number of test failures that bothers
me, so much as the complete radio silence from Konstantin after you've
indicated that you are willing to take the ntfs3 merge request.  It
increases the concerns I personally have that ntfs3 might end up
becoming abandonware after it's been accepted.

ntfs/default: 670 tests, 55 failures, 211 skipped, 34783 seconds
  Failures: generic/003 generic/035 generic/053 generic/062 
    generic/087 generic/088 generic/093 generic/097 generic/099 
    generic/102 generic/105 generic/123 generic/126 generic/193 
    generic/226 generic/237 generic/260 generic/294 generic/306 
    generic/307 generic/314 generic/317 generic/318 generic/319 
    generic/321 generic/355 generic/375 generic/378 generic/409 
    generic/410 generic/411 generic/416 generic/423 generic/424 
    generic/426 generic/427 generic/441 generic/444 generic/452 
    generic/466 generic/467 generic/475 generic/477 generic/500 
    generic/525 generic/529 generic/545 generic/547 generic/553 
    generic/555 generic/564 generic/589 generic/597 generic/629 
    generic/631 

ntfs3/default: 664 tests, 67 failures, 206 skipped, 8106 seconds
  Failures: generic/013 generic/015 generic/034 generic/039 
    generic/040 generic/041 generic/056 generic/057 generic/065 
    generic/066 generic/073 generic/083 generic/090 generic/091 
    generic/092 generic/094 generic/101 generic/102 generic/104 
    generic/106 generic/107 generic/130 generic/225 generic/226 
    generic/228 generic/240 generic/258 generic/263 generic/311 
    generic/317 generic/320 generic/321 generic/322 generic/335 
    generic/336 generic/341 generic/342 generic/343 generic/348 
    generic/360 generic/361 generic/371 generic/376 generic/416 
    generic/427 generic/441 generic/476 generic/480 generic/481 
    generic/483 generic/489 generic/498 generic/502 generic/510 
    generic/512 generic/520 generic/526 generic/527 generic/534 
    generic/538 generic/547 generic/551 generic/552 generic/557 
    generic/598 generic/631 generic/640 

Other file systems for reference:

f2fs/default: 646 tests, 13 failures, 154 skipped, 1812 seconds
  Failures: generic/018 generic/026 generic/050 generic/064
    generic/066 generic/103 generic/219 generic/260 generic/342
    generic/502 generic/506 generic/526 generic/527

btrfs/default: 1075 tests, 8 failures, 219 skipped, 9143 seconds
  Failures: btrfs/012 btrfs/154 btrfs/219 btrfs/220 btrfs/235
    btrfs/241 generic/260 shared/298

xfs/4k: 922 tests, 1 failures, 136 skipped, 5452 seconds
  Failures: xfs/506

ext4/4k: 504 tests, 0 failures, 25 skipped, 6877 seconds

nfs/filestore_v3: 743 tests, 1 failures, 307 skipped, 9261 seconds
  Failures: generic/551

(Note: GCE Filestore uses a Linux kernel so this is testing the nfsv3
client versus a Linux nfsv3 server --- I think the Filestore kernel is
currently using 5.4.129 if I remember correctly.)