xfs
[Top] [All Lists]

Re: [PATCH v4] xfs: rework zero range to prevent invalid i_size updates

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v4] xfs: rework zero range to prevent invalid i_size updates
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Tue, 14 Oct 2014 07:37:58 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141014005058.GH5267@dastard>
References: <1413220285-24886-1-git-send-email-bfoster@xxxxxxxxxx> <20141014001806.GG5267@dastard> <20141014005058.GH5267@dastard>
User-agent: Mutt/1.5.23 (2014-03-12)
On Tue, Oct 14, 2014 at 11:50:58AM +1100, Dave Chinner wrote:
> On Tue, Oct 14, 2014 at 11:18:06AM +1100, Dave Chinner wrote:
> > I'm running 3.17 + for-next + a handful of local patches, but this
> > is the only patch that modifies anything in this area. I'll remove
> > all the other patches I have just to check....
> 
> When this is the only patch on top of 3.17+for-next it still
> triggers.
> 

Interesting, I didn't catch this. I do reproduce with v4 and v3. Note
that this is the assert for having at least 1 indirect block
reservation, so it's a separate problem (not a stale delalloc problem):

http://oss.sgi.com/archives/xfs/2014-09/msg00337.html

What looks like is going on here is this patch regresses current
for-next due to our previous zero range workaround to flush on zero
range.  This was originally reproducible on tot, the zero range flush
quiets it down by forcing delalloc conversion, and this patch
reintroduces it simply by eliminating the flush.

I've just recently got back to fixing that problem. I have a couple
patches that need more testing, but I'll try to get them posted for
review today.

Brian

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@xxxxxxxxxxxxx

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