From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH, RFC] xfs: fix failed write handling
Date: Tue, 9 Nov 2010 16:51:42 +1100 [thread overview]
Message-ID: <20101109055142.GJ2715@dastard> (raw)
In-Reply-To: <20101109002559.GA30016@infradead.org>
On Mon, Nov 08, 2010 at 07:26:00PM -0500, Christoph Hellwig wrote:
> Since the move to the new truncate sequence we call xfs_setattr to
> truncate down excessively instanciated blocks. As shown by the testcase
> in kernel.org BZ #22452 that doesn't work too well. Due to the confusion
> of the internal inode size, and the VFS inode i_size it zeroes data that
> it shouldn't.
>
> But full blown truncate seems like overkill here. We only instanciate
> delayed allocations in the write path, and given that we never released
> the iolock we can't have converted them to real allocations yet either.
>
> The only nasty case is pre-existing preallocation which we need to skip.
> The patch below does that by borrowing code from xfs_aops_discard_page.
> It does pass xfstests for 4k block filesystems and fixes the original
> bug. I'm not quite sure if we could hit a corner case with smaller
> block sizes when parts of a page are preallocated and some not.
Seems likely - preallocated block past EOF are not unusual.
> That
> could be handled by looping around bmapi as long as we find extents
> for our range. The path could probably also be refactored to share
> code with xfs_aops_discard_page. And we probably need the ilock
> just as in that path, but I only got to that when almost through
> xfstests, and the day is over for me today, so let's just get the
> patch out for now.
Yes, definitely need the ilock - that's the only lock that provides
protection for the extent tree.
It looks to me that we need a general "discard delalloc blocks from
range" function - I'll write one (basically the guts of
xfs_aops_discard_page) and convert xfs_aops_discard_page() and this
code to use it....
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:[~2010-11-09 5:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 0:26 [PATCH, RFC] xfs: fix failed write handling Christoph Hellwig
2010-11-09 5:51 ` Dave Chinner [this message]
2010-11-09 11:35 ` Dave Chinner
2010-11-09 13:55 ` Christoph Hellwig
2010-11-17 9:19 ` Christoph Hellwig
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=20101109055142.GJ2715@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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