From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v4] xfs: rework zero range to prevent invalid i_size updates
Date: Tue, 14 Oct 2014 07:37:58 -0400 [thread overview]
Message-ID: <20141014113758.GA64776@bfoster.bfoster> (raw)
In-Reply-To: <20141014005058.GH5267@dastard>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-10-14 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 17:11 [PATCH v4] xfs: rework zero range to prevent invalid i_size updates Brian Foster
2014-10-14 0:18 ` Dave Chinner
2014-10-14 0:50 ` Dave Chinner
2014-10-14 11:37 ` Brian Foster [this message]
2014-10-17 20:20 ` Brian Foster
2014-10-20 1:25 ` Dave Chinner
2014-10-20 12:42 ` Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141014113758.GA64776@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox