Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 8 Jul 2020 16:17:06 +0200
From:   Jan Kara <jack@suse.cz>
To:     Filipe Manana <fdmanana@gmail.com>
Cc:     linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: RWF_NOWAIT writes not failing when writing to a range with holes
Message-ID: <20200708141706.GB5288@quack2.suse.cz>
References: <CAL3q7H4boq-Rsm+OSK5bSBJhu-ywugOdwWfHRQkyuyDC_RoRZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL3q7H4boq-Rsm+OSK5bSBJhu-ywugOdwWfHRQkyuyDC_RoRZA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Hi!

On Mon 15-06-20 18:53:11, Filipe Manana wrote:
> I found out a bug in btrfs where a RWF_NOWRITE does not fail if we
> write to a range that starts with an extent followed by holes (since
> it requires allocating extent(s)).
> 
> When writing a test case for fstests I noticed xfs fails with -EAGAIN
> as expected, but ext4 succeeds just like btrfs currently does:
> 
> mkfs.ext4 -F /dev/sdb
> mount /dev/sdb /mnt
> 
> xfs_io -f -d -c "pwrite -S 0xab -b 256K 0 256K" /mnt/bar
> xfs_io -c "fpunch 64K 64K" /mnt/bar
> sync
> xfs_io -d -c "pwrite -N -V 1 -b 128K -S 0xfe 0 128K" /mnt/bar
> 
> Is this a known bug? Or is there a technical reason that makes it too
> expensive to check no extents will need to be allocated?

Thanks for report! This is actually a fallout of the conversion of ext4
direct IO code to iomap (commit 378f32bab37 "ext4: introduce direct I/O
write using iomap infrastructure"). I'll send a fix.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR