xfs
[Top] [All Lists]

Re: [PATCH 2/4] xfs: byte range granularity for XFS_IOC_ZERO_RANGE

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/4] xfs: byte range granularity for XFS_IOC_ZERO_RANGE
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 29 Nov 2012 15:18:44 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20121129015406.GX6434@dastard>
References: <1354068063-1692-1-git-send-email-david@xxxxxxxxxxxxx> <1354068063-1692-3-git-send-email-david@xxxxxxxxxxxxx> <20121128133305.GA7426@xxxxxxxxxxxxx> <20121129000655.GA6673@xxxxxxxxxxxxx> <20121129015406.GX6434@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Nov 29, 2012 at 12:54:06PM +1100, Dave Chinner wrote:
> On Wed, Nov 28, 2012 at 07:06:55PM -0500, Christoph Hellwig wrote:
> > Actually this seems to trip up an assert in xfstests 290 for me:
> > 
> > 290 0s ...[   45.997814] XFS: Assertion failed: offset + len <= 
> > start_boundary || offset == start_boundary, file: fs/xfs/xfs_vnodeops.c, 
> > line: 2153
> 
> Yes, i got that in one of my overnight QA runs. Haven't had a chance
> to debug it yet.

Ok, I've decided that the ASSERT is simply bogus. It was there
because I initially thought that this breanch woul dbe taken for
sub-page zeroing. In fact, it's not just sub-page zeroing - the
region can span two sub-pages. i.e.:

        0           4096          8192
        +------o------+-------------+
               |----len------|

In this case, offset is 4095, len = 4096, resulting in start/end =
4096. Hence we trigger the pure zeroing branch , and off+len is
clearly greater then start or end....

This is why I put the ASSERT in there, anyway - to validate that my
assumptions that lead to having that branch were correct. Turns out
the assumption was wrong but the code is correct for both cases, so
I'm just going to remove the ASSERT now.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>