Date:   Wed, 4 Aug 2021 09:38:10 +0300
From:   Kari Argillander <kari.argillander@...il.com>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Theodore Ts'o <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        "Leonidas P. Papadakos" <papadakospan@...il.com>,
        Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
        zajec5@...il.com, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hans de Goede <hdegoede@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] vboxsf fixes for 5.14-1

On Tue, Aug 03, 2021 at 06:03:51PM -0700, Darrick J. Wong wrote:
> On Tue, Aug 03, 2021 at 08:49:28PM -0400, Theodore Ts'o wrote:
> > On Tue, Aug 03, 2021 at 05:10:22PM -0700, Linus Torvalds wrote:
> > > The user-space FUSE thing does indeed work reasonably well.
> > > 
> > > It performs horribly badly if you care about things like that, though.
> > > 
> > > In fact, your own numbers kind of show that:
> > > 
> > >   ntfs/default: 670 tests, 55 failures, 211 skipped, 34783 seconds
> > >   ntfs3/default: 664 tests, 67 failures, 206 skipped, 8106 seconds
> > > 
> > > and that's kind of the point of ntfs3.
> > 
> > Sure, although if you run fstress in parallel ntfs3 will lock up, the
> > system hard, and it has at least one lockdep deadlock complaints.
> > It's not up to me, but personally, I'd feel better if *someone* at
> > Paragon Software responded to Darrrick and my queries about their
> > quality assurance, and/or made commitments that they would at least
> > *try* to fix the problems that about 5 minutes of testing using
> > fstests turned up trivially.
> 
> <cough> Yes, my aim was to gauge their interest in actively QAing the
> driver's current problems so that it doesn't become one of the shabby
> Linux filesystem drivers, like <cough>ntfs.
> 
> Note I didn't even ask for a particular percentage of passing tests,
> because I already know that non-Unix filesystems fail the tests that
> look for the more Unix-specific behaviors.
> 
> I really only wanted them to tell /us/ what the baseline is.  IMHO the
> silence from them is a lot more telling.  Both generic/013 and
> generic/475 are basic "try to create files and read and write data to
> them" exercisers; failing those is a red flag.
> 

Konstantin has wrote about these thing see below.

On Thu, 20 Aug 2020 10:20:26 +0000, Konstantin Komarov wrote: 
> xfstests are being one of our standard test suites among others.
> Currently we have the 'generic/339' and 'generic/013' test cases
> failing, working on it now. Other tests either pass or being skipped
> (due to missing features e.g. reflink). 
Source:
https://lore.kernel.org/linux-fsdevel/7538540ab82e4b398a0203564a1f1b23@paragon-software.com/

Also code tells that xfstests is being used in Paragon. In ntfs3/file.c:

/*
* Unwritten area
* NTFS is not able to store several unwritten areas
* Activate 'ntfs_sparse_cluster' to zero new allocated clusters
*
* Dangerous in case:
* 1G of sparsed clusters + 1 cluster of data =>
* valid_size == 1G + 1 cluster
* fallocate(1G) will zero 1G and this can be very long
* xfstest 016/086 will fail without 'ntfs_sparse_cluster'
*/
/*ntfs_sparse_cluster(inode, NULL, vcn,
 *	              min(vcn_v - vcn, clen));
 */

I'm just bringing this thing up because so many has asked and Konstantin
has not responded recently. Hopefully he will soon. Of course is it
little bit worrying that example generic/013 still fails after almoust
year has passed and Konstantin said he is working on it. And it seems that
more tests fails than beginning of review process.

> --D
> 
> > I can even give them patches and configsto make it trivially easy for
> > them to run fstests using KVM or GCE....
> > 
> > 				- Ted

Powered by blists - more mailing lists