[PATCH v4] xfs: rework zero range to prevent invalid i_size updates
Brian Foster
bfoster at redhat.com
Tue Oct 14 06:37:58 CDT 2014
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 at fromorbit.com
More information about the xfs
mailing list