From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH] xfs: flush the range before zero range conversion
Date: Wed, 24 Sep 2014 15:06:31 -0400 [thread overview]
Message-ID: <1411585591-55975-1-git-send-email-bfoster@redhat.com> (raw)
XFS currently discards delalloc blocks within the target range of a zero
range request. Unaligned start and end offsets are zeroed through the
page cache and the internal, aligned blocks are converted to unwritten
extents.
If EOF is page aligned and covered by a delayed allocation extent. The
inode size is not updated until I/O completion. If a zero range request
discards a delalloc range that covers page aligned EOF as such, the
inode size update never occurs. For example:
$ rm -f /mnt/file
$ xfs_io -fc "pwrite 0 64k" -c "zero 60k 4k" /mnt/file
$ stat -c "%s" /mnt/file
65536
$ umount /mnt
$ mount <dev> /mnt
$ stat -c "%s" /mnt/file
61440
Update xfs_zero_file_space() to flush the range rather than discard
delalloc blocks to ensure that inode size updates occur appropriately.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
I suppose we could be more clever here and only flush the range in this
particular scenario, but I'm not sure if there's a major benefit there.
FWIW, this implicitly addresses the indlen==0 assert failures described
in the xfs_bmap_del_extent() rfc, but doesn't necessarily mean we
shouldn't fix that code IMO.
Brian
fs/xfs/xfs_bmap_util.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index d8b77b5..24d634d 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1394,14 +1394,14 @@ xfs_zero_file_space(
if (start_boundary < end_boundary - 1) {
/*
- * punch out delayed allocation blocks and the page cache over
- * the conversion range
+ * Writeback the range to ensure any inode size updates due to
+ * appending writes make it to disk (otherwise we could just
+ * punch out the delalloc blocks).
*/
- xfs_ilock(ip, XFS_ILOCK_EXCL);
- error = xfs_bmap_punch_delalloc_range(ip,
- XFS_B_TO_FSBT(mp, start_boundary),
- XFS_B_TO_FSB(mp, end_boundary - start_boundary));
- xfs_iunlock(ip, XFS_ILOCK_EXCL);
+ error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
+ start_boundary, end_boundary - 1);
+ if (error)
+ goto out;
truncate_pagecache_range(VFS_I(ip), start_boundary,
end_boundary - 1);
--
1.8.3.1
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2014-09-24 19:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 19:06 Brian Foster [this message]
2014-09-25 12:01 ` [PATCH] xfs: flush the range before zero range conversion Dave Chinner
2014-09-25 15:21 ` 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=1411585591-55975-1-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.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