On Thu, May 08, 2014 at 12:11:24PM +0800, Liu Bo wrote:
On Wed, May 07, 2014 at 02:33:18PM +0200, David Disseldorp wrote:
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP, rather than
tripping a Btrfs BUG_ON().
Hi liubo,
On Thu, 8 May 2014 12:11:24 +0800, Liu Bo wrote:
Something different here, I didn't get EIO on 3.15.0-rc4.
Strange, I'm able to consistently reproduce this on a
vanilla v3.15-rc4-202-g30321c7 kernel.
Does that mean the updated test passes successfully for you?
Cheers, David
--
To
On Thu, May 08, 2014 at 11:05:22AM +0200, David Disseldorp wrote:
Hi liubo,
On Thu, 8 May 2014 12:11:24 +0800, Liu Bo wrote:
Something different here, I didn't get EIO on 3.15.0-rc4.
Strange, I'm able to consistently reproduce this on a
vanilla v3.15-rc4-202-g30321c7 kernel.
Does that
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP, rather than
tripping a Btrfs BUG_ON().
This test now trips a new Btrfs bug, in which EIO is returned for
subsequent reads following the second clone range ioctl.
On Wed, May 07, 2014 at 02:33:18PM +0200, David Disseldorp wrote:
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP, rather than
tripping a Btrfs BUG_ON().
This test now trips a new Btrfs bug, in which EIO is
With kernel commit 00fdf13a2e9f313a044288aa59d3b8ec29ff904a, the first
clone-range overwrite attempt now fails with EOPNOTSUPP.
FIXME: The second clone-range causes EIO on subsequent read attempts.
Signed-off-by: David Disseldorp dd...@suse.de
---
tests/btrfs/035 | 10 ++
