From: Liu Bo <bo.li.liu@oracle.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: [PATCH v2] Btrfs: fix abnormal long waiting in fsync
Date: Wed, 16 Jul 2014 15:37:05 +0800 [thread overview]
Message-ID: <1405496225-22416-1-git-send-email-bo.li.liu@oracle.com> (raw)
In-Reply-To: <1405416674-17208-1-git-send-email-bo.li.liu@oracle.com>
xfstests generic/127 detected this problem.
With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only flush
data within the passed range. This is the cause of the above problem,
-- btrfs's fsync has a stage called 'sync log' which will wait for all the
ordered extents it've recorded to finish.
In xfstests/generic/127, with mixed operations such as truncate, fallocate,
punch hole, and mapwrite, we get some pre-allocated extents, and mapwrite will
mmap, and then msync. And I find that msync will wait for quite a long time
(about 20s in my case), thanks to ftrace, it turns out that the previous
fallocate calls 'btrfs_wait_ordered_range()' to flush dirty pages, but as the
range of dirty pages may be larger than 'btrfs_wait_ordered_range()' wants,
there can be some ordered extents created but not getting corresponding pages
flushed, then they're left in memory until we fsync which runs into the
stage 'sync log', and fsync will just wait for the system writeback thread
to flush those pages and get ordered extents finished, so the latency is
inevitable.
This adds a flush similar to btrfs_start_ordered_extent() in
btrfs_wait_logged_extents() to fix that.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
v2:
Move flush part into btrfs_wait_logged_extents() to get the flush range
more precise.
fs/btrfs/ordered-data.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index e12441c..3b52a76 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -484,8 +484,16 @@ void btrfs_wait_logged_extents(struct btrfs_root *log, u64 transid)
log_list);
list_del_init(&ordered->log_list);
spin_unlock_irq(&log->log_extents_lock[index]);
+
+ WARN_ON(!ordered->inode);
+ if (!test_bit(BTRFS_ORDERED_DIRECT, &ordered->flags))
+ filemap_fdatawrite_range(ordered->inode->i_mapping,
+ ordered->file_offset,
+ ordered->file_offset + ordered->len - 1);
+
wait_event(ordered->wait, test_bit(BTRFS_ORDERED_IO_DONE,
&ordered->flags));
+
btrfs_put_ordered_extent(ordered);
spin_lock_irq(&log->log_extents_lock[index]);
}
--
1.8.1.4
next prev parent reply other threads:[~2014-07-16 7:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 9:31 [PATCH] Btrfs: fix abnormal long waiting in fsync Liu Bo
2014-07-15 10:22 ` Miao Xie
2014-07-15 10:41 ` constantine
2014-07-15 10:47 ` Liu Bo
2014-07-16 7:37 ` Liu Bo [this message]
2014-07-16 9:36 ` [PATCH v2] " Miao Xie
2014-07-17 3:00 ` Liu Bo
2014-07-17 8:08 ` [PATCH v3] " Liu Bo
2014-07-17 12:36 ` Chris Mason
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=1405496225-22416-1-git-send-email-bo.li.liu@oracle.com \
--to=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).