From: Dave Chinner <david@fromorbit.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] common: add support for the "local" file system type
Date: Thu, 29 Sep 2016 15:37:52 +1000 [thread overview]
Message-ID: <20160929053752.GJ9806@dastard> (raw)
In-Reply-To: <20160929035636.g2776ggv2cundlrh@thunk.org>
On Wed, Sep 28, 2016 at 11:56:36PM -0400, Theodore Ts'o wrote:
> On Thu, Sep 29, 2016 at 12:16:29PM +1000, Dave Chinner wrote:
> >
> > So, sooper-s3kr3t internal google stuff that you can't talk
> > about and may never see the light of day. When it is announced
> > and released, then let's talk about integration....
>
> Fair enough, I'll carry it as an out-of-tree patch at
>
> https://github.com/tytso/xfstests
>
> ... for anyone else who might find it useful for their purposes.
>
> > xfstests is not designed for validating system call API
> > compliance - it's for exercising /filesystem implementations/.
> > xfstests assumes the syscall API is valid and working, and tries
> > to break the underlying storage implementation. As such, your
> > example really isn't something you should be using xfstests for
> > - it doesn't test anything like what is needed to verify that
> > the "VFS emulation" is valid and complete and working exactly as
> > documented in the linux man pages.
>
> Who says there isn't an underlying file system implementation
> which we want to test? In fact we *are* using the right tool for the job.
Nobody outside the google echo chamber can say, Ted, because you
haven't told anyone what it is you want this for. binary emulation
layers (your example, not mine) don't implement persistent
filesystems - they translate syscalls.
So let's revist this when everyone has the same information
available and we can have an informed discussion....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-09-29 5:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 20:05 [PATCH] common: add support for the "local" file system type Theodore Ts'o
2016-09-26 13:25 ` Eryu Guan
2016-09-26 15:14 ` Theodore Ts'o
2016-09-27 9:55 ` Eryu Guan
2016-09-29 0:01 ` Theodore Ts'o
2016-09-26 22:18 ` Dave Chinner
2016-09-28 23:57 ` Theodore Ts'o
2016-09-29 2:16 ` Dave Chinner
2016-09-29 3:56 ` Theodore Ts'o
2016-09-29 5:37 ` Dave Chinner [this message]
2016-09-29 13:05 ` Theodore Ts'o
2016-09-29 22:49 ` Dave Chinner
2016-09-30 3:43 ` Theodore Ts'o
2016-09-29 13:37 ` Eric Sandeen
2016-09-29 13:57 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2018-05-03 3:43 Theodore Y. Ts'o
2018-05-03 9:22 ` Amir Goldstein
2018-05-03 18:35 ` Theodore Y. Ts'o
2018-05-03 19:24 ` Amir Goldstein
2018-05-06 3:54 ` Eryu Guan
2018-05-12 8:42 ` Eryu Guan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160929053752.GJ9806@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox