On Thu, Apr 21, 2022 at 06:59:42PM +1000, Dave Chinner wrote:
> On Thu, Apr 21, 2022 at 01:41:20PM +0800, Zorro Lang wrote:
> > On Wed, Apr 20, 2022 at 07:52:22PM +0200, Christian Brauner wrote:
> > > Add a regression test for commit 705191b03d50 ("fs: fix acl translation").
> > > This tests whether setting POSIX ACLs on a tmpfs mounted in a
> > > non-initial user and mount namespace works as expected.
> > >
> > > Note, once again the idmapped mount testsuite is grossly misnamed at
> > > this point. It has morphed into a full-blown generic vfs feature
> > > testsuite.
>
> Yup, and that's really important because this is the exact purpose
> for which fstests exists: to cover every aspect of filesystem and
> VFS functionality that needs test coverage.
>
> > Hi,
> >
> > Good to know that, the idmapped-mounts things already been extended to 15k+
> > lines[1] code, it's even much more than the unionmount-testsuite[2]. So I
> > think it's time to think about shifting it from fstests/src to be an independent
> > testsuit,
>
> Please don't do that. That will mean the testing most fs developers
> will get -zero- idmapped-mount test coverage and that's a major
> issue. The kernel code that it covers is non trivial, has deep hooks
> into every filesystem and these tests ensure that we filesystem
> developers don't accidentally break it. It *needs* to be a part of
> every filesystem developer's test environment, and we already have
> that by having it integrated into fstests.
Sure, I won't do that wilfully, just try to ask how we can improve this
huge and 'keep growing' idmapped-mounts.c, not tend to remove the whole
idmapped-mount testing coverage :)
I agree with you, fstests won't reduce existed fs testing coverage, or
much more carefully to do that if have to do. fstests will be more compatible,
And welcome more contributors choose fstests to be their regression
testsuite.
Thanks,
Zirong
>
> This is what we want - we want fstests to be the place that fs
> developers add new tests to cover new functionality, and so all
> filesystems get coverage of that functionality as part of the
> development process.
>
> This is exactly what we've spent the last 20 years building xfstests
> into - it's gone from a filesystem specific tests suite to
> supporting a dozen different filesystems and covers heaps of VFS
> functionality as well.
>
> As such, I think the last thing we want to be doing is telling
> people to "take their code elsewhere". It sends the wrong message -
> we want people to incorporate their complex test code into fstests
> because that benefits every developer who uses fstests in their
> daily workflow. The more test coverage we get, the better, and the
> more test code we get integrated into fstests the better off we will
> be.
>
> > we can learn what 35c7a37928fd ("overlay: run unionmount testsuite test
> > cases") did, maintain idmapped-mounts testsuite outside, then let fstests to be a
> > wrapper to run it.
>
> The unionmount tests suite was never a part of fstests like the
> idmapped tests suite is. Very few developers know it exists, let
> alone install it. Even fewer run it because it's part of the overlay
> tests and almost nobody except overlay developers run overlay
> testing...
>
>
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
