Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: fdmanana@kernel.org, fstests@vger.kernel.org,
	linux-btrfs@vger.kernel.org, Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] generic: test the correctness of several cases of RWF_NOWAIT writes
Date: Fri, 16 Oct 2020 16:57:57 +1100	[thread overview]
Message-ID: <20201016055757.GA7322@dread.disaster.area> (raw)
In-Reply-To: <20201015161355.GI7037@quack2.suse.cz>

On Thu, Oct 15, 2020 at 06:13:56PM +0200, Jan Kara wrote:
> On Thu 15-10-20 16:36:38, fdmanana@kernel.org wrote:
> > From: Filipe Manana <fdmanana@suse.com>
> > 
> > Verify some attempts to write into a file using RWF_NOWAIT:
> > 
> > 1) Writing into a fallocated extent that starts at eof should work;
> 
> Why? We need to update i_size which requires transaction start and e.g.
> ext4 does not support that in non-blocking mode...

Right, different filesystems behave differently given similar
pre-conditions. That's not a bug, that's exactly how RWF_NOWAIT is
expected to be implemented by each filesystem....

> > 2) Writing into a hole should fail;
> > 3) Writing into a range that is partially allocated should fail.

Same for these - these are situations where a -specific filesystem
implementation- might block, not a situation where the RWF_NOWAIT
API specification says that IO submission "should fail" and hence
return EAGAIN.

> > This is motivated by several bugs that btrfs and ext4 had and were fixed
> > by the following kernel commits:
> > 
> >   4b1946284dd6 ("btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof")
> >   260a63395f90 ("btrfs: fix RWF_NOWAIT write not failling when we need to cow")
> >   0b3171b6d195 ("ext4: do not block RWF_NOWAIT dio write on unallocated space")
> > 
> > At the moment, on a 5.9-rc6 kernel at least, ext4 is failing for case 1),
> > but when I found and fixed case 1) in btrfs, around kernel 5.7, it was not
> > failing on ext4, so some regression happened in the meanwhile. For xfs and
> > btrfs on a 5.9 kernel, all the three cases pass.

Sure, until we propagate IOMAP_NOWAIT far enough into the allocation
code that allocation will either succeed without blocking or fail
without changing anything.  At which point, the filesystem behaviour
is absolutely correct according to the RWF_NOWAIT specification, but
the test is most definitely wrong.

IOWs, I think any test that says "RWF_NOWAIT IO in a <specific
situation> must do <specific thing>" is incorrect. RWF_NOWAIT simply
does not not define behaviour like this, and different filesystems
will do different things given the same file layouts...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2020-10-16  5:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 15:36 [PATCH] generic: test the correctness of several cases of RWF_NOWAIT writes fdmanana
2020-10-15 16:13 ` Jan Kara
2020-10-15 16:38   ` Filipe Manana
2020-10-16  5:57   ` Dave Chinner [this message]
2020-10-16  8:46     ` Jan Kara
2020-10-16  9:25       ` Filipe Manana

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=20201016055757.GA7322@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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