diff options
author | Theodore Ts'o <tytso@mit.edu> | 2013-02-09 03:59:22 +0100 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2013-02-09 03:59:22 +0100 |
commit | 9924a92a8c217576bd2a2b1bbbb854462f1a00ae (patch) | |
tree | 5c4eaee350e38cd2854fd6029da9f2a822ee184e /fs/ext4/xattr.c | |
parent | ext4: move the jbd2 wrapper functions out of super.c (diff) | |
download | linux-9924a92a8c217576bd2a2b1bbbb854462f1a00ae.tar.xz linux-9924a92a8c217576bd2a2b1bbbb854462f1a00ae.zip |
ext4: pass context information to jbd2__journal_start()
So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.
The recommended way for finding the longer-running handles is:
T=/sys/kernel/debug/tracing
EVENT=$T/events/jbd2/jbd2_handle_stats
echo "interval > 5" > $EVENT/filter
echo 1 > $EVENT/enable
./run-my-fs-benchmark
cat $T/trace > /tmp/problem-handles
This will list handles that were active for longer than 20ms. Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation. Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:
postmark-2917 [000] .... 196.435786: jbd2_handle_stats: dev 254,32
tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
dirtied_blocks 0
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to '')
-rw-r--r-- | fs/ext4/xattr.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index c68990c392c7..2efc5600b03b 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1175,7 +1175,7 @@ retry: if (ext4_has_inline_data(inode)) credits += ext4_writepage_trans_blocks(inode) + 1; - handle = ext4_journal_start(inode, credits); + handle = ext4_journal_start(inode, EXT4_HT_XATTR, credits); if (IS_ERR(handle)) { error = PTR_ERR(handle); } else { |