From: Dave Chinner <david@fromorbit.com>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] generic/461: Test RWF_NOWAIT
Date: Thu, 28 Sep 2017 16:02:04 +1000 [thread overview]
Message-ID: <20170928060204.GI10621@dastard> (raw)
In-Reply-To: <a474211d-66a0-51bf-e12c-a5f5b7a146cc@suse.de>
On Wed, Sep 27, 2017 at 09:09:55PM -0500, Goldwyn Rodrigues wrote:
>
>
> On 09/27/2017 08:51 PM, Dave Chinner wrote:
> > On Wed, Sep 27, 2017 at 05:24:49PM -0500, Goldwyn Rodrigues wrote:
> >>
> >>
> >> On 09/27/2017 04:51 PM, Dave Chinner wrote:
> >>> On Wed, Sep 27, 2017 at 04:39:20PM -0500, Goldwyn Rodrigues wrote:
> >>>>
> >>>>
> >>>> On 09/27/2017 04:34 PM, Dave Chinner wrote:
> >>>>> On Wed, Sep 27, 2017 at 02:10:02PM -0500, Goldwyn Rodrigues wrote:
> >>>>>> From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> >>>>>>
> >>>>>> Tests the RWF_NOWAIT flag so the I/O returns immediately on
> >>>>>> a new file, without any block allocations.
> >>>>>>
> >>>>>> A new program which includes the pwritev2() call is used. This allows
> >>>>>> passing flags for the I/O to be performed.
> >>>>>
> >>>>> Rather than write a one-off test program for this that effectively
> >>>>> replicates xfs_io pread/pwrite functionality, please add RWF_NOWAIT
> >>>>> flag support to xfs_io.
> >>>>>
> >>>>
> >>>> This one off program is required because xfs_io does not support partial
> >>>> writes. It tries to do that within the loop and does not return the
> >>>> number of bytes written. This is required for test generic/462.
> >>>
> >>> Then please also extend xfs_io to support partial reads and writes
> >>> in the manner you need.
> >>>
> >>
> >> That will break existing tests which rely on nothing but the error
> >> returned in case of partial writes.
> >
> > So trigger necessary partial write behaviour only when the CLI
> > option to use RWF_NOWAIT is present....
> >
>
> Partial write test case is not related to RWF_NOWAIT test case. These
> are two separate test cases.
>
> Anyways, I am working on implementing this. Would you prefer pwritev2 be
> a separate subcommand calling pwritev2() or should I transform pwritev()
> to pwritev2()? The system call is relatively new and there are
> overlapping features such as RWF_DSYNC and RWF_SYNC. I am assuming the
> former.
If pwritev2 exists at build time, build in support for it. If it
returns ENOSYS or it is not present at build time, fall back to
pwritev()...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2017-09-28 6:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 19:10 [PATCH 1/2] generic/461: Test RWF_NOWAIT Goldwyn Rodrigues
2017-09-27 19:10 ` [PATCH 2/2] generic/462: Partial direct write test Goldwyn Rodrigues
2017-09-27 21:34 ` [PATCH 1/2] generic/461: Test RWF_NOWAIT Dave Chinner
2017-09-27 21:39 ` Goldwyn Rodrigues
2017-09-27 21:51 ` Dave Chinner
2017-09-27 22:24 ` Goldwyn Rodrigues
2017-09-28 1:51 ` Dave Chinner
2017-09-28 2:09 ` Goldwyn Rodrigues
2017-09-28 6:02 ` Dave Chinner [this message]
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=20170928060204.GI10621@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=rgoldwyn@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.