2018-04-03 20:23:33 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2008-01-08 23:46:30 +03:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2007 Oracle. All rights reserved.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/slab.h>
|
2008-04-30 21:59:35 +04:00
|
|
|
#include <linux/blkdev.h>
|
2008-07-22 19:18:09 +04:00
|
|
|
#include <linux/writeback.h>
|
2019-04-01 11:29:58 +03:00
|
|
|
#include <linux/sched/mm.h>
|
2019-08-21 19:48:25 +03:00
|
|
|
#include "misc.h"
|
2008-01-08 23:46:30 +03:00
|
|
|
#include "ctree.h"
|
|
|
|
#include "transaction.h"
|
|
|
|
#include "btrfs_inode.h"
|
2008-07-17 20:53:50 +04:00
|
|
|
#include "extent_io.h"
|
2013-05-15 11:48:23 +04:00
|
|
|
#include "disk-io.h"
|
2016-03-10 12:26:59 +03:00
|
|
|
#include "compression.h"
|
2019-06-19 22:12:00 +03:00
|
|
|
#include "delalloc-space.h"
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
#include "qgroup.h"
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2012-09-06 14:01:51 +04:00
|
|
|
static struct kmem_cache *btrfs_ordered_extent_cache;
|
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
static u64 entry_end(struct btrfs_ordered_extent *entry)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2019-12-03 04:34:19 +03:00
|
|
|
if (entry->file_offset + entry->num_bytes < entry->file_offset)
|
2008-07-17 20:53:50 +04:00
|
|
|
return (u64)-1;
|
2019-12-03 04:34:19 +03:00
|
|
|
return entry->file_offset + entry->num_bytes;
|
2008-01-08 23:46:30 +03:00
|
|
|
}
|
|
|
|
|
2008-09-29 23:18:18 +04:00
|
|
|
/* returns NULL if the insertion worked, or it returns the node it did find
|
|
|
|
* in the tree
|
|
|
|
*/
|
2008-07-17 20:53:50 +04:00
|
|
|
static struct rb_node *tree_insert(struct rb_root *root, u64 file_offset,
|
|
|
|
struct rb_node *node)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2009-01-06 05:25:51 +03:00
|
|
|
struct rb_node **p = &root->rb_node;
|
|
|
|
struct rb_node *parent = NULL;
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_extent *entry;
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2009-01-06 05:25:51 +03:00
|
|
|
while (*p) {
|
2008-01-08 23:46:30 +03:00
|
|
|
parent = *p;
|
2008-07-17 20:53:50 +04:00
|
|
|
entry = rb_entry(parent, struct btrfs_ordered_extent, rb_node);
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
if (file_offset < entry->file_offset)
|
2008-01-08 23:46:30 +03:00
|
|
|
p = &(*p)->rb_left;
|
2008-07-17 20:53:50 +04:00
|
|
|
else if (file_offset >= entry_end(entry))
|
2008-01-08 23:46:30 +03:00
|
|
|
p = &(*p)->rb_right;
|
|
|
|
else
|
|
|
|
return parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
rb_link_node(node, parent, p);
|
|
|
|
rb_insert_color(node, root);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-09-29 23:18:18 +04:00
|
|
|
/*
|
|
|
|
* look for a given offset in the tree, and if it can't be found return the
|
|
|
|
* first lesser offset
|
|
|
|
*/
|
2008-07-17 20:53:50 +04:00
|
|
|
static struct rb_node *__tree_search(struct rb_root *root, u64 file_offset,
|
|
|
|
struct rb_node **prev_ret)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2009-01-06 05:25:51 +03:00
|
|
|
struct rb_node *n = root->rb_node;
|
2008-01-08 23:46:30 +03:00
|
|
|
struct rb_node *prev = NULL;
|
2008-07-17 20:53:50 +04:00
|
|
|
struct rb_node *test;
|
|
|
|
struct btrfs_ordered_extent *entry;
|
|
|
|
struct btrfs_ordered_extent *prev_entry = NULL;
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2009-01-06 05:25:51 +03:00
|
|
|
while (n) {
|
2008-07-17 20:53:50 +04:00
|
|
|
entry = rb_entry(n, struct btrfs_ordered_extent, rb_node);
|
2008-01-08 23:46:30 +03:00
|
|
|
prev = n;
|
|
|
|
prev_entry = entry;
|
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
if (file_offset < entry->file_offset)
|
2008-01-08 23:46:30 +03:00
|
|
|
n = n->rb_left;
|
2008-07-17 20:53:50 +04:00
|
|
|
else if (file_offset >= entry_end(entry))
|
2008-01-08 23:46:30 +03:00
|
|
|
n = n->rb_right;
|
|
|
|
else
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
if (!prev_ret)
|
|
|
|
return NULL;
|
|
|
|
|
2009-01-06 05:25:51 +03:00
|
|
|
while (prev && file_offset >= entry_end(prev_entry)) {
|
2008-07-17 20:53:50 +04:00
|
|
|
test = rb_next(prev);
|
|
|
|
if (!test)
|
|
|
|
break;
|
|
|
|
prev_entry = rb_entry(test, struct btrfs_ordered_extent,
|
|
|
|
rb_node);
|
|
|
|
if (file_offset < entry_end(prev_entry))
|
|
|
|
break;
|
|
|
|
|
|
|
|
prev = test;
|
|
|
|
}
|
|
|
|
if (prev)
|
|
|
|
prev_entry = rb_entry(prev, struct btrfs_ordered_extent,
|
|
|
|
rb_node);
|
2009-01-06 05:25:51 +03:00
|
|
|
while (prev && file_offset < entry_end(prev_entry)) {
|
2008-07-17 20:53:50 +04:00
|
|
|
test = rb_prev(prev);
|
|
|
|
if (!test)
|
|
|
|
break;
|
|
|
|
prev_entry = rb_entry(test, struct btrfs_ordered_extent,
|
|
|
|
rb_node);
|
|
|
|
prev = test;
|
2008-01-08 23:46:30 +03:00
|
|
|
}
|
|
|
|
*prev_ret = prev;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-09-29 23:18:18 +04:00
|
|
|
/*
|
|
|
|
* helper to check if a given offset is inside a given entry
|
|
|
|
*/
|
2008-07-17 20:53:50 +04:00
|
|
|
static int offset_in_entry(struct btrfs_ordered_extent *entry, u64 file_offset)
|
|
|
|
{
|
|
|
|
if (file_offset < entry->file_offset ||
|
2019-12-03 04:34:19 +03:00
|
|
|
entry->file_offset + entry->num_bytes <= file_offset)
|
2008-07-17 20:53:50 +04:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2010-05-23 19:00:55 +04:00
|
|
|
static int range_overlaps(struct btrfs_ordered_extent *entry, u64 file_offset,
|
|
|
|
u64 len)
|
|
|
|
{
|
|
|
|
if (file_offset + len <= entry->file_offset ||
|
2019-12-03 04:34:19 +03:00
|
|
|
entry->file_offset + entry->num_bytes <= file_offset)
|
2010-05-23 19:00:55 +04:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-09-29 23:18:18 +04:00
|
|
|
/*
|
|
|
|
* look find the first ordered struct that has this offset, otherwise
|
|
|
|
* the first one less than this offset
|
|
|
|
*/
|
2008-07-17 20:53:50 +04:00
|
|
|
static inline struct rb_node *tree_search(struct btrfs_ordered_inode_tree *tree,
|
|
|
|
u64 file_offset)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2008-07-17 20:53:50 +04:00
|
|
|
struct rb_root *root = &tree->tree;
|
2011-02-01 03:54:59 +03:00
|
|
|
struct rb_node *prev = NULL;
|
2008-01-08 23:46:30 +03:00
|
|
|
struct rb_node *ret;
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_extent *entry;
|
|
|
|
|
|
|
|
if (tree->last) {
|
|
|
|
entry = rb_entry(tree->last, struct btrfs_ordered_extent,
|
|
|
|
rb_node);
|
|
|
|
if (offset_in_entry(entry, file_offset))
|
|
|
|
return tree->last;
|
|
|
|
}
|
|
|
|
ret = __tree_search(root, file_offset, &prev);
|
2008-01-08 23:46:30 +03:00
|
|
|
if (!ret)
|
2008-07-17 20:53:50 +04:00
|
|
|
ret = prev;
|
|
|
|
if (ret)
|
|
|
|
tree->last = ret;
|
2008-01-08 23:46:30 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
/*
|
|
|
|
* Allocate and add a new ordered_extent into the per-inode tree.
|
2008-07-17 21:53:27 +04:00
|
|
|
*
|
|
|
|
* The tree is given a single reference on the ordered extent that was
|
|
|
|
* inserted.
|
|
|
|
*/
|
2020-06-03 08:55:01 +03:00
|
|
|
static int __btrfs_add_ordered_extent(struct btrfs_inode *inode, u64 file_offset,
|
2019-12-03 04:34:19 +03:00
|
|
|
u64 disk_bytenr, u64 num_bytes,
|
|
|
|
u64 disk_num_bytes, int type, int dio,
|
|
|
|
int compress_type)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2020-06-03 08:55:01 +03:00
|
|
|
struct btrfs_root *root = inode->root;
|
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
struct btrfs_ordered_inode_tree *tree = &inode->ordered_tree;
|
2008-07-17 20:53:50 +04:00
|
|
|
struct rb_node *node;
|
|
|
|
struct btrfs_ordered_extent *entry;
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (type == BTRFS_ORDERED_NOCOW || type == BTRFS_ORDERED_PREALLOC) {
|
|
|
|
/* For nocow write, we can release the qgroup rsv right now */
|
2020-06-03 08:55:11 +03:00
|
|
|
ret = btrfs_qgroup_free_data(inode, NULL, file_offset, num_bytes);
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
ret = 0;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The ordered extent has reserved qgroup space, release now
|
|
|
|
* and pass the reserved number for qgroup_record to free.
|
|
|
|
*/
|
2020-06-03 08:55:18 +03:00
|
|
|
ret = btrfs_qgroup_release_data(inode, file_offset, num_bytes);
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2012-09-06 14:01:51 +04:00
|
|
|
entry = kmem_cache_zalloc(btrfs_ordered_extent_cache, GFP_NOFS);
|
2008-01-08 23:46:30 +03:00
|
|
|
if (!entry)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
entry->file_offset = file_offset;
|
2019-12-03 04:34:19 +03:00
|
|
|
entry->disk_bytenr = disk_bytenr;
|
|
|
|
entry->num_bytes = num_bytes;
|
|
|
|
entry->disk_num_bytes = disk_num_bytes;
|
|
|
|
entry->bytes_left = num_bytes;
|
2020-06-03 08:55:01 +03:00
|
|
|
entry->inode = igrab(&inode->vfs_inode);
|
2010-12-17 09:21:50 +03:00
|
|
|
entry->compress_type = compress_type;
|
2013-08-29 21:57:21 +04:00
|
|
|
entry->truncated_len = (u64)-1;
|
btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak
[BUG]
The following simple workload from fsstress can lead to qgroup reserved
data space leak:
0/0: creat f0 x:0 0 0
0/0: creat add id=0,parent=-1
0/1: write f0[259 1 0 0 0 0] [600030,27288] 0
0/4: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 64 627318] return 25, fallback to stat()
0/4: dwrite f0[259 1 0 0 64 627318] [610304,106496] 0
This would cause btrfs qgroup to leak 20480 bytes for data reserved
space. If btrfs qgroup limit is enabled, such leak can lead to
unexpected early EDQUOT and unusable space.
[CAUSE]
When doing direct IO, kernel will try to writeback existing buffered
page cache, then invalidate them:
generic_file_direct_write()
|- filemap_write_and_wait_range();
|- invalidate_inode_pages2_range();
However for btrfs, the bi_end_io hook doesn't finish all its heavy work
right after bio ends. In fact, it delays its work further:
submit_extent_page(end_io_func=end_bio_extent_writepage);
end_bio_extent_writepage()
|- btrfs_writepage_endio_finish_ordered()
|- btrfs_init_work(finish_ordered_fn);
<<< Work queue execution >>>
finish_ordered_fn()
|- btrfs_finish_ordered_io();
|- Clear qgroup bits
This means, when filemap_write_and_wait_range() returns,
btrfs_finish_ordered_io() is not guaranteed to be executed, thus the
qgroup bits for related range are not cleared.
Now into how the leak happens, this will only focus on the overlapping
part of buffered and direct IO part.
1. After buffered write
The inode had the following range with QGROUP_RESERVED bit:
596 616K
|///////////////|
Qgroup reserved data space: 20K
2. Writeback part for range [596K, 616K)
Write back finished, but btrfs_finish_ordered_io() not get called
yet.
So we still have:
596K 616K
|///////////////|
Qgroup reserved data space: 20K
3. Pages for range [596K, 616K) get released
This will clear all qgroup bits, but don't update the reserved data
space.
So we have:
596K 616K
| |
Qgroup reserved data space: 20K
That number doesn't match the qgroup bit range anymore.
4. Dio prepare space for range [596K, 700K)
Qgroup reserved data space for that range, we got:
596K 616K 700K
|///////////////|///////////////////////|
Qgroup reserved data space: 20K + 104K = 124K
5. btrfs_finish_ordered_range() gets executed for range [596K, 616K)
Qgroup free reserved space for that range, we got:
596K 616K 700K
| |///////////////////////|
We need to free that range of reserved space.
Qgroup reserved data space: 124K - 20K = 104K
6. btrfs_finish_ordered_range() gets executed for range [596K, 700K)
However qgroup bit for range [596K, 616K) is already cleared in
previous step, so we only free 84K for qgroup reserved space.
596K 616K 700K
| | |
We need to free that range of reserved space.
Qgroup reserved data space: 104K - 84K = 20K
Now there is no way to release that 20K unless disabling qgroup or
unmounting the fs.
[FIX]
This patch will change the timing of btrfs_qgroup_release/free_data()
call. Here it uses buffered COW write as an example.
The new timing | The old timing
----------------------------------------+---------------------------------------
btrfs_buffered_write() | btrfs_buffered_write()
|- btrfs_qgroup_reserve_data() | |- btrfs_qgroup_reserve_data()
|
btrfs_run_delalloc_range() | btrfs_run_delalloc_range()
|- btrfs_add_ordered_extent() |
|- btrfs_qgroup_release_data() |
The reserved is passed into |
btrfs_ordered_extent structure |
|
btrfs_finish_ordered_io() | btrfs_finish_ordered_io()
|- The reserved space is passed to | |- btrfs_qgroup_release_data()
btrfs_qgroup_record | The resereved space is passed
| to btrfs_qgroup_recrod
|
btrfs_qgroup_account_extents() | btrfs_qgroup_account_extents()
|- btrfs_qgroup_free_refroot() | |- btrfs_qgroup_free_refroot()
The point of such change is to ensure, when ordered extents are
submitted, the qgroup reserved space is already released, to keep the
timing aligned with file_write_and_wait_range().
So that qgroup data reserved space is all bound to btrfs_ordered_extent
and solve the timing mismatch.
Fixes: f695fdcef83a ("btrfs: qgroup: Introduce functions to release/free qgroup reserve data space")
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-10 04:04:43 +03:00
|
|
|
entry->qgroup_rsv = ret;
|
2021-01-21 09:13:54 +03:00
|
|
|
|
|
|
|
ASSERT(type == BTRFS_ORDERED_REGULAR ||
|
|
|
|
type == BTRFS_ORDERED_NOCOW ||
|
|
|
|
type == BTRFS_ORDERED_PREALLOC ||
|
|
|
|
type == BTRFS_ORDERED_COMPRESSED);
|
|
|
|
set_bit(type, &entry->flags);
|
2008-07-24 19:57:52 +04:00
|
|
|
|
2019-04-10 22:56:09 +03:00
|
|
|
if (dio) {
|
2019-12-03 04:34:19 +03:00
|
|
|
percpu_counter_add_batch(&fs_info->dio_bytes, num_bytes,
|
2019-04-10 22:56:09 +03:00
|
|
|
fs_info->delalloc_batch);
|
2010-05-23 19:00:55 +04:00
|
|
|
set_bit(BTRFS_ORDERED_DIRECT, &entry->flags);
|
2019-04-10 22:56:09 +03:00
|
|
|
}
|
2010-05-23 19:00:55 +04:00
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
/* one ref for the tree */
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_set(&entry->refs, 1);
|
2008-07-17 20:53:50 +04:00
|
|
|
init_waitqueue_head(&entry->wait);
|
|
|
|
INIT_LIST_HEAD(&entry->list);
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
INIT_LIST_HEAD(&entry->log_list);
|
2008-07-24 19:57:52 +04:00
|
|
|
INIT_LIST_HEAD(&entry->root_extent_list);
|
2012-10-25 13:41:36 +04:00
|
|
|
INIT_LIST_HEAD(&entry->work_list);
|
|
|
|
init_completion(&entry->completion);
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2020-08-31 14:42:40 +03:00
|
|
|
trace_btrfs_ordered_extent_add(inode, entry);
|
Btrfs: add initial tracepoint support for btrfs
Tracepoints can provide insight into why btrfs hits bugs and be greatly
helpful for debugging, e.g
dd-7822 [000] 2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
dd-7822 [000] 2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
btrfs-transacti-7804 [001] 2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
flush-btrfs-2-7821 [001] 2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
flush-btrfs-2-7821 [001] 2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
flush-btrfs-2-7821 [001] 2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
flush-btrfs-2-7821 [000] 2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
Here is what I have added:
1) ordere_extent:
btrfs_ordered_extent_add
btrfs_ordered_extent_remove
btrfs_ordered_extent_start
btrfs_ordered_extent_put
These provide critical information to understand how ordered_extents are
updated.
2) extent_map:
btrfs_get_extent
extent_map is used in both read and write cases, and it is useful for tracking
how btrfs specific IO is running.
3) writepage:
__extent_writepage
btrfs_writepage_end_io_hook
Pages are cirtical resourses and produce a lot of corner cases during writeback,
so it is valuable to know how page is written to disk.
4) inode:
btrfs_inode_new
btrfs_inode_request
btrfs_inode_evict
These can show where and when a inode is created, when a inode is evicted.
5) sync:
btrfs_sync_file
btrfs_sync_fs
These show sync arguments.
6) transaction:
btrfs_transaction_commit
In transaction based filesystem, it will be useful to know the generation and
who does commit.
7) back reference and cow:
btrfs_delayed_tree_ref
btrfs_delayed_data_ref
btrfs_delayed_ref_head
btrfs_cow_block
Btrfs natively supports back references, these tracepoints are helpful on
understanding btrfs's COW mechanism.
8) chunk:
btrfs_chunk_alloc
btrfs_chunk_free
Chunk is a link between physical offset and logical offset, and stands for space
infomation in btrfs, and these are helpful on tracing space things.
9) reserved_extent:
btrfs_reserved_extent_alloc
btrfs_reserved_extent_free
These can show how btrfs uses its space.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-03-24 14:18:59 +03:00
|
|
|
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
node = tree_insert(&tree->tree, file_offset,
|
|
|
|
&entry->rb_node);
|
2011-10-04 07:22:33 +04:00
|
|
|
if (node)
|
2019-11-29 12:38:13 +03:00
|
|
|
btrfs_panic(fs_info, -EEXIST,
|
|
|
|
"inconsistency in ordered tree at offset %llu",
|
|
|
|
file_offset);
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2009-01-06 05:25:51 +03:00
|
|
|
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_lock(&root->ordered_extent_lock);
|
2008-07-24 19:57:52 +04:00
|
|
|
list_add_tail(&entry->root_extent_list,
|
2013-05-15 11:48:23 +04:00
|
|
|
&root->ordered_extents);
|
|
|
|
root->nr_ordered_extents++;
|
|
|
|
if (root->nr_ordered_extents == 1) {
|
2016-06-23 01:54:23 +03:00
|
|
|
spin_lock(&fs_info->ordered_root_lock);
|
2013-05-15 11:48:23 +04:00
|
|
|
BUG_ON(!list_empty(&root->ordered_root));
|
2016-06-23 01:54:23 +03:00
|
|
|
list_add_tail(&root->ordered_root, &fs_info->ordered_roots);
|
|
|
|
spin_unlock(&fs_info->ordered_root_lock);
|
2013-05-15 11:48:23 +04:00
|
|
|
}
|
|
|
|
spin_unlock(&root->ordered_extent_lock);
|
2008-07-24 19:57:52 +04:00
|
|
|
|
2017-10-19 21:15:55 +03:00
|
|
|
/*
|
|
|
|
* We don't need the count_max_extents here, we can assume that all of
|
|
|
|
* that work has been done at higher layers, so this is truly the
|
|
|
|
* smallest the extent is going to get.
|
|
|
|
*/
|
2020-06-03 08:55:01 +03:00
|
|
|
spin_lock(&inode->lock);
|
|
|
|
btrfs_mod_outstanding_extents(inode, 1);
|
|
|
|
spin_unlock(&inode->lock);
|
2017-10-19 21:15:55 +03:00
|
|
|
|
2008-01-08 23:46:30 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-06-03 08:55:13 +03:00
|
|
|
int btrfs_add_ordered_extent(struct btrfs_inode *inode, u64 file_offset,
|
2019-12-03 04:34:19 +03:00
|
|
|
u64 disk_bytenr, u64 num_bytes, u64 disk_num_bytes,
|
|
|
|
int type)
|
2010-05-23 19:00:55 +04:00
|
|
|
{
|
2021-01-21 09:13:54 +03:00
|
|
|
ASSERT(type == BTRFS_ORDERED_REGULAR ||
|
|
|
|
type == BTRFS_ORDERED_NOCOW ||
|
|
|
|
type == BTRFS_ORDERED_PREALLOC);
|
2020-06-03 08:55:13 +03:00
|
|
|
return __btrfs_add_ordered_extent(inode, file_offset, disk_bytenr,
|
2019-12-03 04:34:19 +03:00
|
|
|
num_bytes, disk_num_bytes, type, 0,
|
2010-12-17 09:21:50 +03:00
|
|
|
BTRFS_COMPRESS_NONE);
|
2010-05-23 19:00:55 +04:00
|
|
|
}
|
|
|
|
|
2020-06-03 08:55:30 +03:00
|
|
|
int btrfs_add_ordered_extent_dio(struct btrfs_inode *inode, u64 file_offset,
|
2019-12-03 04:34:19 +03:00
|
|
|
u64 disk_bytenr, u64 num_bytes,
|
|
|
|
u64 disk_num_bytes, int type)
|
2010-05-23 19:00:55 +04:00
|
|
|
{
|
2021-01-21 09:13:54 +03:00
|
|
|
ASSERT(type == BTRFS_ORDERED_REGULAR ||
|
|
|
|
type == BTRFS_ORDERED_NOCOW ||
|
|
|
|
type == BTRFS_ORDERED_PREALLOC);
|
2020-06-03 08:55:30 +03:00
|
|
|
return __btrfs_add_ordered_extent(inode, file_offset, disk_bytenr,
|
2019-12-03 04:34:19 +03:00
|
|
|
num_bytes, disk_num_bytes, type, 1,
|
2010-12-17 09:21:50 +03:00
|
|
|
BTRFS_COMPRESS_NONE);
|
|
|
|
}
|
|
|
|
|
2020-06-03 08:55:15 +03:00
|
|
|
int btrfs_add_ordered_extent_compress(struct btrfs_inode *inode, u64 file_offset,
|
2019-12-03 04:34:19 +03:00
|
|
|
u64 disk_bytenr, u64 num_bytes,
|
2021-01-21 09:13:54 +03:00
|
|
|
u64 disk_num_bytes, int compress_type)
|
2010-12-17 09:21:50 +03:00
|
|
|
{
|
2021-01-21 09:13:54 +03:00
|
|
|
ASSERT(compress_type != BTRFS_COMPRESS_NONE);
|
2020-06-03 08:55:15 +03:00
|
|
|
return __btrfs_add_ordered_extent(inode, file_offset, disk_bytenr,
|
2021-01-21 09:13:54 +03:00
|
|
|
num_bytes, disk_num_bytes,
|
|
|
|
BTRFS_ORDERED_COMPRESSED, 0,
|
2010-12-17 09:21:50 +03:00
|
|
|
compress_type);
|
2010-05-23 19:00:55 +04:00
|
|
|
}
|
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* Add a struct btrfs_ordered_sum into the list of checksums to be inserted
|
2008-07-18 14:17:13 +04:00
|
|
|
* when an ordered extent is finished. If the list covers more than one
|
|
|
|
* ordered extent, it is split across multiples.
|
2008-07-17 21:53:27 +04:00
|
|
|
*/
|
2019-04-10 16:16:11 +03:00
|
|
|
void btrfs_add_ordered_sum(struct btrfs_ordered_extent *entry,
|
2012-03-01 17:56:26 +04:00
|
|
|
struct btrfs_ordered_sum *sum)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_inode_tree *tree;
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2019-04-10 16:16:11 +03:00
|
|
|
tree = &BTRFS_I(entry->inode)->ordered_tree;
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
list_add_tail(&sum->list, &entry->list);
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2008-01-08 23:46:30 +03:00
|
|
|
}
|
|
|
|
|
2010-11-29 03:56:33 +03:00
|
|
|
/*
|
2020-12-22 08:59:24 +03:00
|
|
|
* Finish IO for one ordered extent across a given range. The range can
|
|
|
|
* contain several ordered extents.
|
2010-11-29 03:56:33 +03:00
|
|
|
*
|
2020-12-22 08:59:24 +03:00
|
|
|
* @found_ret: Return the finished ordered extent
|
|
|
|
* @file_offset: File offset for the finished IO
|
|
|
|
* Will also be updated to one byte past the range that is
|
|
|
|
* recordered as finished. This allows caller to walk forward.
|
|
|
|
* @io_size: Length of the finish IO range
|
|
|
|
* @uptodate: If the IO finished without problem
|
2010-11-29 03:56:33 +03:00
|
|
|
*
|
2020-12-22 08:59:24 +03:00
|
|
|
* Return true if any ordered extent is finished in the range, and update
|
|
|
|
* @found_ret and @file_offset.
|
|
|
|
* Return false otherwise.
|
|
|
|
*
|
|
|
|
* NOTE: Although The range can cross multiple ordered extents, only one
|
|
|
|
* ordered extent will be updated during one call. The caller is responsible to
|
|
|
|
* iterate all ordered extents in the range.
|
2010-11-29 03:56:33 +03:00
|
|
|
*/
|
2020-12-22 08:59:24 +03:00
|
|
|
bool btrfs_dec_test_first_ordered_pending(struct btrfs_inode *inode,
|
|
|
|
struct btrfs_ordered_extent **finished_ret,
|
2012-05-02 22:00:54 +04:00
|
|
|
u64 *file_offset, u64 io_size, int uptodate)
|
2010-11-29 03:56:33 +03:00
|
|
|
{
|
2020-06-03 08:55:23 +03:00
|
|
|
struct btrfs_fs_info *fs_info = inode->root->fs_info;
|
|
|
|
struct btrfs_ordered_inode_tree *tree = &inode->ordered_tree;
|
2010-11-29 03:56:33 +03:00
|
|
|
struct rb_node *node;
|
|
|
|
struct btrfs_ordered_extent *entry = NULL;
|
2020-12-22 08:59:24 +03:00
|
|
|
bool finished = false;
|
2012-05-02 22:00:54 +04:00
|
|
|
unsigned long flags;
|
2010-11-29 03:56:33 +03:00
|
|
|
u64 dec_end;
|
|
|
|
u64 dec_start;
|
|
|
|
u64 to_dec;
|
|
|
|
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irqsave(&tree->lock, flags);
|
2010-11-29 03:56:33 +03:00
|
|
|
node = tree_search(tree, *file_offset);
|
2020-12-22 08:59:24 +03:00
|
|
|
if (!node)
|
2010-11-29 03:56:33 +03:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
entry = rb_entry(node, struct btrfs_ordered_extent, rb_node);
|
2020-12-22 08:59:24 +03:00
|
|
|
if (!offset_in_entry(entry, *file_offset))
|
2010-11-29 03:56:33 +03:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
dec_start = max(*file_offset, entry->file_offset);
|
2019-12-03 04:34:19 +03:00
|
|
|
dec_end = min(*file_offset + io_size,
|
|
|
|
entry->file_offset + entry->num_bytes);
|
2010-11-29 03:56:33 +03:00
|
|
|
*file_offset = dec_end;
|
|
|
|
if (dec_start > dec_end) {
|
2016-06-23 01:54:23 +03:00
|
|
|
btrfs_crit(fs_info, "bad ordering dec_start %llu end %llu",
|
|
|
|
dec_start, dec_end);
|
2010-11-29 03:56:33 +03:00
|
|
|
}
|
|
|
|
to_dec = dec_end - dec_start;
|
|
|
|
if (to_dec > entry->bytes_left) {
|
2016-06-23 01:54:23 +03:00
|
|
|
btrfs_crit(fs_info,
|
|
|
|
"bad ordered accounting left %llu size %llu",
|
|
|
|
entry->bytes_left, to_dec);
|
2010-11-29 03:56:33 +03:00
|
|
|
}
|
|
|
|
entry->bytes_left -= to_dec;
|
2012-05-02 22:00:54 +04:00
|
|
|
if (!uptodate)
|
|
|
|
set_bit(BTRFS_ORDERED_IOERR, &entry->flags);
|
|
|
|
|
2014-03-06 09:54:56 +04:00
|
|
|
if (entry->bytes_left == 0) {
|
2020-12-22 08:59:24 +03:00
|
|
|
/*
|
|
|
|
* Ensure only one caller can set the flag and finished_ret
|
|
|
|
* accordingly
|
|
|
|
*/
|
|
|
|
finished = !test_and_set_bit(BTRFS_ORDERED_IO_DONE, &entry->flags);
|
2018-02-26 18:15:17 +03:00
|
|
|
/* test_and_set_bit implies a barrier */
|
|
|
|
cond_wake_up_nomb(&entry->wait);
|
2014-03-06 09:54:56 +04:00
|
|
|
}
|
2010-11-29 03:56:33 +03:00
|
|
|
out:
|
2020-12-22 08:59:24 +03:00
|
|
|
if (finished && finished_ret && entry) {
|
|
|
|
*finished_ret = entry;
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&entry->refs);
|
2010-11-29 03:56:33 +03:00
|
|
|
}
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irqrestore(&tree->lock, flags);
|
2020-12-22 08:59:24 +03:00
|
|
|
return finished;
|
2010-11-29 03:56:33 +03:00
|
|
|
}
|
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
2020-12-22 08:59:24 +03:00
|
|
|
* Finish IO for one ordered extent across a given range. The range can only
|
|
|
|
* contain one ordered extent.
|
|
|
|
*
|
|
|
|
* @cached: The cached ordered extent. If not NULL, we can skip the tree
|
|
|
|
* search and use the ordered extent directly.
|
|
|
|
* Will be also used to store the finished ordered extent.
|
|
|
|
* @file_offset: File offset for the finished IO
|
|
|
|
* @io_size: Length of the finish IO range
|
|
|
|
* @uptodate: If the IO finishes without problem
|
2008-07-17 21:53:27 +04:00
|
|
|
*
|
2020-12-22 08:59:24 +03:00
|
|
|
* Return true if the ordered extent is finished in the range, and update
|
|
|
|
* @cached.
|
|
|
|
* Return false otherwise.
|
|
|
|
*
|
|
|
|
* NOTE: The range can NOT cross multiple ordered extents.
|
|
|
|
* Thus caller should ensure the range doesn't cross ordered extents.
|
2008-07-17 21:53:27 +04:00
|
|
|
*/
|
2020-12-22 08:59:24 +03:00
|
|
|
bool btrfs_dec_test_ordered_pending(struct btrfs_inode *inode,
|
|
|
|
struct btrfs_ordered_extent **cached,
|
|
|
|
u64 file_offset, u64 io_size, int uptodate)
|
2008-01-08 23:46:30 +03:00
|
|
|
{
|
2020-08-31 14:42:41 +03:00
|
|
|
struct btrfs_ordered_inode_tree *tree = &inode->ordered_tree;
|
2008-01-08 23:46:30 +03:00
|
|
|
struct rb_node *node;
|
2010-02-02 23:51:14 +03:00
|
|
|
struct btrfs_ordered_extent *entry = NULL;
|
2012-05-02 22:00:54 +04:00
|
|
|
unsigned long flags;
|
2020-12-22 08:59:24 +03:00
|
|
|
bool finished = false;
|
2008-07-17 20:53:50 +04:00
|
|
|
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irqsave(&tree->lock, flags);
|
|
|
|
if (cached && *cached) {
|
|
|
|
entry = *cached;
|
|
|
|
goto have_entry;
|
|
|
|
}
|
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
node = tree_search(tree, file_offset);
|
2020-12-22 08:59:24 +03:00
|
|
|
if (!node)
|
2008-07-17 20:53:50 +04:00
|
|
|
goto out;
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2008-07-17 20:53:50 +04:00
|
|
|
entry = rb_entry(node, struct btrfs_ordered_extent, rb_node);
|
2012-05-02 22:00:54 +04:00
|
|
|
have_entry:
|
2020-12-22 08:59:24 +03:00
|
|
|
if (!offset_in_entry(entry, file_offset))
|
2008-07-17 20:53:50 +04:00
|
|
|
goto out;
|
|
|
|
|
2020-12-22 08:59:24 +03:00
|
|
|
if (io_size > entry->bytes_left)
|
2020-08-31 14:42:41 +03:00
|
|
|
btrfs_crit(inode->root->fs_info,
|
2013-12-20 20:37:06 +04:00
|
|
|
"bad ordered accounting left %llu size %llu",
|
2013-08-20 15:20:07 +04:00
|
|
|
entry->bytes_left, io_size);
|
2020-12-22 08:59:24 +03:00
|
|
|
|
2009-09-03 00:53:46 +04:00
|
|
|
entry->bytes_left -= io_size;
|
2012-05-02 22:00:54 +04:00
|
|
|
if (!uptodate)
|
|
|
|
set_bit(BTRFS_ORDERED_IOERR, &entry->flags);
|
|
|
|
|
2014-03-06 09:54:56 +04:00
|
|
|
if (entry->bytes_left == 0) {
|
2020-12-22 08:59:24 +03:00
|
|
|
/*
|
|
|
|
* Ensure only one caller can set the flag and finished_ret
|
|
|
|
* accordingly
|
|
|
|
*/
|
|
|
|
finished = !test_and_set_bit(BTRFS_ORDERED_IO_DONE, &entry->flags);
|
2018-02-26 18:15:17 +03:00
|
|
|
/* test_and_set_bit implies a barrier */
|
|
|
|
cond_wake_up_nomb(&entry->wait);
|
2014-03-06 09:54:56 +04:00
|
|
|
}
|
2008-07-17 20:53:50 +04:00
|
|
|
out:
|
2020-12-22 08:59:24 +03:00
|
|
|
if (finished && cached && entry) {
|
2010-02-02 23:51:14 +03:00
|
|
|
*cached = entry;
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&entry->refs);
|
2010-02-02 23:51:14 +03:00
|
|
|
}
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irqrestore(&tree->lock, flags);
|
2020-12-22 08:59:24 +03:00
|
|
|
return finished;
|
2008-07-17 20:53:50 +04:00
|
|
|
}
|
2008-01-08 23:46:30 +03:00
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* used to drop a reference on an ordered extent. This will free
|
|
|
|
* the extent if the last reference is dropped
|
|
|
|
*/
|
2012-03-01 17:56:26 +04:00
|
|
|
void btrfs_put_ordered_extent(struct btrfs_ordered_extent *entry)
|
2008-07-17 20:53:50 +04:00
|
|
|
{
|
2008-07-17 20:54:15 +04:00
|
|
|
struct list_head *cur;
|
|
|
|
struct btrfs_ordered_sum *sum;
|
|
|
|
|
2020-08-31 14:42:40 +03:00
|
|
|
trace_btrfs_ordered_extent_put(BTRFS_I(entry->inode), entry);
|
Btrfs: add initial tracepoint support for btrfs
Tracepoints can provide insight into why btrfs hits bugs and be greatly
helpful for debugging, e.g
dd-7822 [000] 2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
dd-7822 [000] 2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
btrfs-transacti-7804 [001] 2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
flush-btrfs-2-7821 [001] 2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
flush-btrfs-2-7821 [001] 2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
flush-btrfs-2-7821 [001] 2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
flush-btrfs-2-7821 [000] 2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
Here is what I have added:
1) ordere_extent:
btrfs_ordered_extent_add
btrfs_ordered_extent_remove
btrfs_ordered_extent_start
btrfs_ordered_extent_put
These provide critical information to understand how ordered_extents are
updated.
2) extent_map:
btrfs_get_extent
extent_map is used in both read and write cases, and it is useful for tracking
how btrfs specific IO is running.
3) writepage:
__extent_writepage
btrfs_writepage_end_io_hook
Pages are cirtical resourses and produce a lot of corner cases during writeback,
so it is valuable to know how page is written to disk.
4) inode:
btrfs_inode_new
btrfs_inode_request
btrfs_inode_evict
These can show where and when a inode is created, when a inode is evicted.
5) sync:
btrfs_sync_file
btrfs_sync_fs
These show sync arguments.
6) transaction:
btrfs_transaction_commit
In transaction based filesystem, it will be useful to know the generation and
who does commit.
7) back reference and cow:
btrfs_delayed_tree_ref
btrfs_delayed_data_ref
btrfs_delayed_ref_head
btrfs_cow_block
Btrfs natively supports back references, these tracepoints are helpful on
understanding btrfs's COW mechanism.
8) chunk:
btrfs_chunk_alloc
btrfs_chunk_free
Chunk is a link between physical offset and logical offset, and stands for space
infomation in btrfs, and these are helpful on tracing space things.
9) reserved_extent:
btrfs_reserved_extent_alloc
btrfs_reserved_extent_free
These can show how btrfs uses its space.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-03-24 14:18:59 +03:00
|
|
|
|
2017-03-03 11:55:13 +03:00
|
|
|
if (refcount_dec_and_test(&entry->refs)) {
|
2015-07-01 14:13:10 +03:00
|
|
|
ASSERT(list_empty(&entry->root_extent_list));
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
ASSERT(list_empty(&entry->log_list));
|
2015-07-01 14:13:10 +03:00
|
|
|
ASSERT(RB_EMPTY_NODE(&entry->rb_node));
|
2012-05-02 22:00:54 +04:00
|
|
|
if (entry->inode)
|
|
|
|
btrfs_add_delayed_iput(entry->inode);
|
2009-01-06 05:25:51 +03:00
|
|
|
while (!list_empty(&entry->list)) {
|
2008-07-17 20:54:15 +04:00
|
|
|
cur = entry->list.next;
|
|
|
|
sum = list_entry(cur, struct btrfs_ordered_sum, list);
|
|
|
|
list_del(&sum->list);
|
2019-04-01 11:29:58 +03:00
|
|
|
kvfree(sum);
|
2008-07-17 20:54:15 +04:00
|
|
|
}
|
2012-09-06 14:01:51 +04:00
|
|
|
kmem_cache_free(btrfs_ordered_extent_cache, entry);
|
2008-07-17 20:54:15 +04:00
|
|
|
}
|
2008-01-08 23:46:30 +03:00
|
|
|
}
|
2008-01-15 16:40:48 +03:00
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* remove an ordered extent from the tree. No references are dropped
|
2012-05-02 22:00:54 +04:00
|
|
|
* and waiters are woken up.
|
2008-07-17 21:53:27 +04:00
|
|
|
*/
|
2020-09-18 12:15:50 +03:00
|
|
|
void btrfs_remove_ordered_extent(struct btrfs_inode *btrfs_inode,
|
2012-05-02 22:00:54 +04:00
|
|
|
struct btrfs_ordered_extent *entry)
|
2008-01-15 16:40:48 +03:00
|
|
|
{
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_inode_tree *tree;
|
2017-10-19 21:15:55 +03:00
|
|
|
struct btrfs_root *root = btrfs_inode->root;
|
2020-09-18 12:15:50 +03:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
2008-01-15 16:40:48 +03:00
|
|
|
struct rb_node *node;
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
bool pending;
|
2008-01-15 16:40:48 +03:00
|
|
|
|
2017-10-19 21:15:55 +03:00
|
|
|
/* This is paired with btrfs_add_ordered_extent. */
|
|
|
|
spin_lock(&btrfs_inode->lock);
|
|
|
|
btrfs_mod_outstanding_extents(btrfs_inode, -1);
|
|
|
|
spin_unlock(&btrfs_inode->lock);
|
|
|
|
if (root != fs_info->tree_root)
|
2019-12-03 04:34:19 +03:00
|
|
|
btrfs_delalloc_release_metadata(btrfs_inode, entry->num_bytes,
|
|
|
|
false);
|
2017-10-19 21:15:55 +03:00
|
|
|
|
2019-04-10 22:56:09 +03:00
|
|
|
if (test_bit(BTRFS_ORDERED_DIRECT, &entry->flags))
|
2019-12-03 04:34:19 +03:00
|
|
|
percpu_counter_add_batch(&fs_info->dio_bytes, -entry->num_bytes,
|
2019-04-10 22:56:09 +03:00
|
|
|
fs_info->delalloc_batch);
|
|
|
|
|
2017-10-19 21:15:55 +03:00
|
|
|
tree = &btrfs_inode->ordered_tree;
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
node = &entry->rb_node;
|
2008-01-15 16:40:48 +03:00
|
|
|
rb_erase(node, &tree->tree);
|
2015-07-01 14:13:10 +03:00
|
|
|
RB_CLEAR_NODE(node);
|
2013-11-22 22:54:58 +04:00
|
|
|
if (tree->last == node)
|
|
|
|
tree->last = NULL;
|
2008-07-17 20:53:50 +04:00
|
|
|
set_bit(BTRFS_ORDERED_COMPLETE, &entry->flags);
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
pending = test_and_clear_bit(BTRFS_ORDERED_PENDING, &entry->flags);
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2008-07-24 19:57:52 +04:00
|
|
|
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
/*
|
|
|
|
* The current running transaction is waiting on us, we need to let it
|
|
|
|
* know that we're complete and wake it up.
|
|
|
|
*/
|
|
|
|
if (pending) {
|
|
|
|
struct btrfs_transaction *trans;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The checks for trans are just a formality, it should be set,
|
|
|
|
* but if it isn't we don't want to deref/assert under the spin
|
|
|
|
* lock, so be nice and check if trans is set, but ASSERT() so
|
|
|
|
* if it isn't set a developer will notice.
|
|
|
|
*/
|
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
trans = fs_info->running_transaction;
|
|
|
|
if (trans)
|
|
|
|
refcount_inc(&trans->use_count);
|
|
|
|
spin_unlock(&fs_info->trans_lock);
|
|
|
|
|
|
|
|
ASSERT(trans);
|
|
|
|
if (trans) {
|
|
|
|
if (atomic_dec_and_test(&trans->pending_ordered))
|
|
|
|
wake_up(&trans->pending_wait);
|
|
|
|
btrfs_put_transaction(trans);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_lock(&root->ordered_extent_lock);
|
2008-07-24 19:57:52 +04:00
|
|
|
list_del_init(&entry->root_extent_list);
|
2013-05-15 11:48:23 +04:00
|
|
|
root->nr_ordered_extents--;
|
2009-03-31 21:27:11 +04:00
|
|
|
|
2020-09-18 12:15:50 +03:00
|
|
|
trace_btrfs_ordered_extent_remove(btrfs_inode, entry);
|
Btrfs: add initial tracepoint support for btrfs
Tracepoints can provide insight into why btrfs hits bugs and be greatly
helpful for debugging, e.g
dd-7822 [000] 2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
dd-7822 [000] 2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
btrfs-transacti-7804 [001] 2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
flush-btrfs-2-7821 [001] 2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
flush-btrfs-2-7821 [001] 2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
flush-btrfs-2-7821 [001] 2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
flush-btrfs-2-7821 [000] 2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
Here is what I have added:
1) ordere_extent:
btrfs_ordered_extent_add
btrfs_ordered_extent_remove
btrfs_ordered_extent_start
btrfs_ordered_extent_put
These provide critical information to understand how ordered_extents are
updated.
2) extent_map:
btrfs_get_extent
extent_map is used in both read and write cases, and it is useful for tracking
how btrfs specific IO is running.
3) writepage:
__extent_writepage
btrfs_writepage_end_io_hook
Pages are cirtical resourses and produce a lot of corner cases during writeback,
so it is valuable to know how page is written to disk.
4) inode:
btrfs_inode_new
btrfs_inode_request
btrfs_inode_evict
These can show where and when a inode is created, when a inode is evicted.
5) sync:
btrfs_sync_file
btrfs_sync_fs
These show sync arguments.
6) transaction:
btrfs_transaction_commit
In transaction based filesystem, it will be useful to know the generation and
who does commit.
7) back reference and cow:
btrfs_delayed_tree_ref
btrfs_delayed_data_ref
btrfs_delayed_ref_head
btrfs_cow_block
Btrfs natively supports back references, these tracepoints are helpful on
understanding btrfs's COW mechanism.
8) chunk:
btrfs_chunk_alloc
btrfs_chunk_free
Chunk is a link between physical offset and logical offset, and stands for space
infomation in btrfs, and these are helpful on tracing space things.
9) reserved_extent:
btrfs_reserved_extent_alloc
btrfs_reserved_extent_free
These can show how btrfs uses its space.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-03-24 14:18:59 +03:00
|
|
|
|
2013-05-15 11:48:23 +04:00
|
|
|
if (!root->nr_ordered_extents) {
|
2016-06-23 01:54:23 +03:00
|
|
|
spin_lock(&fs_info->ordered_root_lock);
|
2013-05-15 11:48:23 +04:00
|
|
|
BUG_ON(list_empty(&root->ordered_root));
|
|
|
|
list_del_init(&root->ordered_root);
|
2016-06-23 01:54:23 +03:00
|
|
|
spin_unlock(&fs_info->ordered_root_lock);
|
2013-05-15 11:48:23 +04:00
|
|
|
}
|
|
|
|
spin_unlock(&root->ordered_extent_lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
wake_up(&entry->wait);
|
2008-01-15 16:40:48 +03:00
|
|
|
}
|
|
|
|
|
2014-02-28 06:46:19 +04:00
|
|
|
static void btrfs_run_ordered_extent_work(struct btrfs_work *work)
|
2012-10-25 13:41:36 +04:00
|
|
|
{
|
|
|
|
struct btrfs_ordered_extent *ordered;
|
|
|
|
|
|
|
|
ordered = container_of(work, struct btrfs_ordered_extent, flush_work);
|
2020-09-18 12:15:53 +03:00
|
|
|
btrfs_start_ordered_extent(ordered, 1);
|
2012-10-25 13:41:36 +04:00
|
|
|
complete(&ordered->completion);
|
|
|
|
}
|
|
|
|
|
2008-09-29 23:18:18 +04:00
|
|
|
/*
|
|
|
|
* wait for all the ordered extents in a root. This is done when balancing
|
|
|
|
* space between drives.
|
|
|
|
*/
|
2017-06-23 19:48:21 +03:00
|
|
|
u64 btrfs_wait_ordered_extents(struct btrfs_root *root, u64 nr,
|
2016-04-26 17:36:38 +03:00
|
|
|
const u64 range_start, const u64 range_len)
|
2008-07-24 19:57:52 +04:00
|
|
|
{
|
2016-06-23 01:54:23 +03:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
2016-04-26 17:36:38 +03:00
|
|
|
LIST_HEAD(splice);
|
|
|
|
LIST_HEAD(skipped);
|
|
|
|
LIST_HEAD(works);
|
2012-10-25 13:41:36 +04:00
|
|
|
struct btrfs_ordered_extent *ordered, *next;
|
2017-06-23 19:48:21 +03:00
|
|
|
u64 count = 0;
|
2016-04-26 17:36:38 +03:00
|
|
|
const u64 range_end = range_start + range_len;
|
2008-07-24 19:57:52 +04:00
|
|
|
|
2014-03-06 09:55:02 +04:00
|
|
|
mutex_lock(&root->ordered_extent_mutex);
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_lock(&root->ordered_extent_lock);
|
|
|
|
list_splice_init(&root->ordered_extents, &splice);
|
2013-11-04 19:13:25 +04:00
|
|
|
while (!list_empty(&splice) && nr) {
|
2013-05-15 11:48:23 +04:00
|
|
|
ordered = list_first_entry(&splice, struct btrfs_ordered_extent,
|
|
|
|
root_extent_list);
|
2016-04-26 17:36:38 +03:00
|
|
|
|
2019-12-03 04:34:19 +03:00
|
|
|
if (range_end <= ordered->disk_bytenr ||
|
|
|
|
ordered->disk_bytenr + ordered->disk_num_bytes <= range_start) {
|
2016-04-26 17:36:38 +03:00
|
|
|
list_move_tail(&ordered->root_extent_list, &skipped);
|
|
|
|
cond_resched_lock(&root->ordered_extent_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2013-05-15 11:48:23 +04:00
|
|
|
list_move_tail(&ordered->root_extent_list,
|
|
|
|
&root->ordered_extents);
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&ordered->refs);
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_unlock(&root->ordered_extent_lock);
|
2008-07-24 19:57:52 +04:00
|
|
|
|
2014-02-28 06:46:09 +04:00
|
|
|
btrfs_init_work(&ordered->flush_work,
|
|
|
|
btrfs_run_ordered_extent_work, NULL, NULL);
|
2013-05-15 11:48:23 +04:00
|
|
|
list_add_tail(&ordered->work_list, &works);
|
2016-06-23 01:54:23 +03:00
|
|
|
btrfs_queue_work(fs_info->flush_workers, &ordered->flush_work);
|
2008-07-24 19:57:52 +04:00
|
|
|
|
2012-10-25 13:41:36 +04:00
|
|
|
cond_resched();
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_lock(&root->ordered_extent_lock);
|
2017-06-23 19:48:21 +03:00
|
|
|
if (nr != U64_MAX)
|
2013-11-04 19:13:25 +04:00
|
|
|
nr--;
|
|
|
|
count++;
|
2008-07-24 19:57:52 +04:00
|
|
|
}
|
2016-04-26 17:36:38 +03:00
|
|
|
list_splice_tail(&skipped, &root->ordered_extents);
|
2013-11-04 19:13:25 +04:00
|
|
|
list_splice_tail(&splice, &root->ordered_extents);
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_unlock(&root->ordered_extent_lock);
|
2012-10-25 13:41:36 +04:00
|
|
|
|
|
|
|
list_for_each_entry_safe(ordered, next, &works, work_list) {
|
|
|
|
list_del_init(&ordered->work_list);
|
|
|
|
wait_for_completion(&ordered->completion);
|
|
|
|
btrfs_put_ordered_extent(ordered);
|
|
|
|
cond_resched();
|
|
|
|
}
|
2014-03-06 09:55:02 +04:00
|
|
|
mutex_unlock(&root->ordered_extent_mutex);
|
2013-11-04 19:13:25 +04:00
|
|
|
|
|
|
|
return count;
|
2008-07-24 19:57:52 +04:00
|
|
|
}
|
|
|
|
|
Btrfs: fix block group remaining RO forever after error during device replace
When doing a device replace, while at scrub.c:scrub_enumerate_chunks(), we
set the block group to RO mode and then wait for any ongoing writes into
extents of the block group to complete. While doing that wait we overwrite
the value of the variable 'ret' and can break out of the loop if an error
happens without turning the block group back into RW mode. So what happens
is the following:
1) btrfs_inc_block_group_ro() returns 0, meaning it set the block group
to RO mode (its ->ro field set to 1 or incremented to some value > 1);
2) Then btrfs_wait_ordered_roots() returns a value > 0;
3) Then if either joining or committing the transaction fails, we break
out of the loop wihtout calling btrfs_dec_block_group_ro(), leaving
the block group in RO mode forever.
To fix this, just remove the code that waits for ongoing writes to extents
of the block group, since it's not needed because in the initial setup
phase of a device replace operation, before starting to find all chunks
and their extents, we set the target device for replace while holding
fs_info->dev_replace->rwsem, which ensures that after releasing that
semaphore, any writes into the source device are made to the target device
as well (__btrfs_map_block() guarantees that). So while at
scrub_enumerate_chunks() we only need to worry about finding and copying
extents (from the source device to the target device) that were written
before we started the device replace operation.
Fixes: f0e9b7d6401959 ("Btrfs: fix race setting block group readonly during device replace")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-11-14 21:02:43 +03:00
|
|
|
void btrfs_wait_ordered_roots(struct btrfs_fs_info *fs_info, u64 nr,
|
2017-06-23 19:48:21 +03:00
|
|
|
const u64 range_start, const u64 range_len)
|
2013-05-15 11:48:23 +04:00
|
|
|
{
|
|
|
|
struct btrfs_root *root;
|
|
|
|
struct list_head splice;
|
2017-06-23 19:48:21 +03:00
|
|
|
u64 done;
|
2013-05-15 11:48:23 +04:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&splice);
|
|
|
|
|
2014-03-06 09:54:55 +04:00
|
|
|
mutex_lock(&fs_info->ordered_operations_mutex);
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_lock(&fs_info->ordered_root_lock);
|
|
|
|
list_splice_init(&fs_info->ordered_roots, &splice);
|
2013-11-04 19:13:25 +04:00
|
|
|
while (!list_empty(&splice) && nr) {
|
2013-05-15 11:48:23 +04:00
|
|
|
root = list_first_entry(&splice, struct btrfs_root,
|
|
|
|
ordered_root);
|
2020-01-24 17:33:01 +03:00
|
|
|
root = btrfs_grab_root(root);
|
2013-05-15 11:48:23 +04:00
|
|
|
BUG_ON(!root);
|
|
|
|
list_move_tail(&root->ordered_root,
|
|
|
|
&fs_info->ordered_roots);
|
|
|
|
spin_unlock(&fs_info->ordered_root_lock);
|
|
|
|
|
2016-04-26 17:36:38 +03:00
|
|
|
done = btrfs_wait_ordered_extents(root, nr,
|
|
|
|
range_start, range_len);
|
2020-01-24 17:33:01 +03:00
|
|
|
btrfs_put_root(root);
|
2013-05-15 11:48:23 +04:00
|
|
|
|
|
|
|
spin_lock(&fs_info->ordered_root_lock);
|
2017-06-23 19:48:21 +03:00
|
|
|
if (nr != U64_MAX) {
|
2013-11-04 19:13:25 +04:00
|
|
|
nr -= done;
|
|
|
|
}
|
2013-05-15 11:48:23 +04:00
|
|
|
}
|
2013-11-14 13:33:21 +04:00
|
|
|
list_splice_tail(&splice, &fs_info->ordered_roots);
|
2013-05-15 11:48:23 +04:00
|
|
|
spin_unlock(&fs_info->ordered_root_lock);
|
2014-03-06 09:54:55 +04:00
|
|
|
mutex_unlock(&fs_info->ordered_operations_mutex);
|
2013-05-15 11:48:23 +04:00
|
|
|
}
|
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* Used to start IO or wait for a given ordered extent to finish.
|
|
|
|
*
|
|
|
|
* If wait is one, this effectively waits on page writeback for all the pages
|
|
|
|
* in the extent, and it waits on the io completion code to insert
|
|
|
|
* metadata into the btree corresponding to the extent
|
|
|
|
*/
|
2020-09-18 12:15:53 +03:00
|
|
|
void btrfs_start_ordered_extent(struct btrfs_ordered_extent *entry, int wait)
|
2008-07-17 20:53:50 +04:00
|
|
|
{
|
|
|
|
u64 start = entry->file_offset;
|
2019-12-03 04:34:19 +03:00
|
|
|
u64 end = start + entry->num_bytes - 1;
|
2020-09-18 12:15:53 +03:00
|
|
|
struct btrfs_inode *inode = BTRFS_I(entry->inode);
|
2008-05-27 18:55:43 +04:00
|
|
|
|
2020-09-18 12:15:53 +03:00
|
|
|
trace_btrfs_ordered_extent_start(inode, entry);
|
Btrfs: add initial tracepoint support for btrfs
Tracepoints can provide insight into why btrfs hits bugs and be greatly
helpful for debugging, e.g
dd-7822 [000] 2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
dd-7822 [000] 2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
btrfs-transacti-7804 [001] 2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
btrfs-transacti-7804 [001] 2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
flush-btrfs-2-7821 [001] 2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
flush-btrfs-2-7821 [001] 2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
flush-btrfs-2-7821 [001] 2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
flush-btrfs-2-7821 [000] 2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
btrfs-endio-wri-7800 [001] 2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
Here is what I have added:
1) ordere_extent:
btrfs_ordered_extent_add
btrfs_ordered_extent_remove
btrfs_ordered_extent_start
btrfs_ordered_extent_put
These provide critical information to understand how ordered_extents are
updated.
2) extent_map:
btrfs_get_extent
extent_map is used in both read and write cases, and it is useful for tracking
how btrfs specific IO is running.
3) writepage:
__extent_writepage
btrfs_writepage_end_io_hook
Pages are cirtical resourses and produce a lot of corner cases during writeback,
so it is valuable to know how page is written to disk.
4) inode:
btrfs_inode_new
btrfs_inode_request
btrfs_inode_evict
These can show where and when a inode is created, when a inode is evicted.
5) sync:
btrfs_sync_file
btrfs_sync_fs
These show sync arguments.
6) transaction:
btrfs_transaction_commit
In transaction based filesystem, it will be useful to know the generation and
who does commit.
7) back reference and cow:
btrfs_delayed_tree_ref
btrfs_delayed_data_ref
btrfs_delayed_ref_head
btrfs_cow_block
Btrfs natively supports back references, these tracepoints are helpful on
understanding btrfs's COW mechanism.
8) chunk:
btrfs_chunk_alloc
btrfs_chunk_free
Chunk is a link between physical offset and logical offset, and stands for space
infomation in btrfs, and these are helpful on tracing space things.
9) reserved_extent:
btrfs_reserved_extent_alloc
btrfs_reserved_extent_free
These can show how btrfs uses its space.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-03-24 14:18:59 +03:00
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* pages in the range can be dirty, clean or writeback. We
|
|
|
|
* start IO on any dirty ones so the wait doesn't stall waiting
|
2012-07-25 19:12:06 +04:00
|
|
|
* for the flusher thread to find them
|
2008-07-17 21:53:27 +04:00
|
|
|
*/
|
2010-05-23 19:00:55 +04:00
|
|
|
if (!test_bit(BTRFS_ORDERED_DIRECT, &entry->flags))
|
2020-09-18 12:15:53 +03:00
|
|
|
filemap_fdatawrite_range(inode->vfs_inode.i_mapping, start, end);
|
Btrfs: Add zlib compression support
This is a large change for adding compression on reading and writing,
both for inline and regular extents. It does some fairly large
surgery to the writeback paths.
Compression is off by default and enabled by mount -o compress. Even
when the -o compress mount option is not used, it is possible to read
compressed extents off the disk.
If compression for a given set of pages fails to make them smaller, the
file is flagged to avoid future compression attempts later.
* While finding delalloc extents, the pages are locked before being sent down
to the delalloc handler. This allows the delalloc handler to do complex things
such as cleaning the pages, marking them writeback and starting IO on their
behalf.
* Inline extents are inserted at delalloc time now. This allows us to compress
the data before inserting the inline extent, and it allows us to insert
an inline extent that spans multiple pages.
* All of the in-memory extent representations (extent_map.c, ordered-data.c etc)
are changed to record both an in-memory size and an on disk size, as well
as a flag for compression.
From a disk format point of view, the extent pointers in the file are changed
to record the on disk size of a given extent and some encoding flags.
Space in the disk format is allocated for compression encoding, as well
as encryption and a generic 'other' field. Neither the encryption or the
'other' field are currently used.
In order to limit the amount of data read for a single random read in the
file, the size of a compressed extent is limited to 128k. This is a
software only limit, the disk format supports u64 sized compressed extents.
In order to limit the ram consumed while processing extents, the uncompressed
size of a compressed extent is limited to 256k. This is a software only limit
and will be subject to tuning later.
Checksumming is still done on compressed extents, and it is done on the
uncompressed version of the data. This way additional encodings can be
layered on without having to figure out which encoding to checksum.
Compression happens at delalloc time, which is basically singled threaded because
it is usually done by a single pdflush thread. This makes it tricky to
spread the compression load across all the cpus on the box. We'll have to
look at parallel pdflush walks of dirty inodes at a later time.
Decompression is hooked into readpages and it does spread across CPUs nicely.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2008-10-29 21:49:59 +03:00
|
|
|
if (wait) {
|
2008-07-17 20:53:50 +04:00
|
|
|
wait_event(entry->wait, test_bit(BTRFS_ORDERED_COMPLETE,
|
|
|
|
&entry->flags));
|
Btrfs: Add zlib compression support
This is a large change for adding compression on reading and writing,
both for inline and regular extents. It does some fairly large
surgery to the writeback paths.
Compression is off by default and enabled by mount -o compress. Even
when the -o compress mount option is not used, it is possible to read
compressed extents off the disk.
If compression for a given set of pages fails to make them smaller, the
file is flagged to avoid future compression attempts later.
* While finding delalloc extents, the pages are locked before being sent down
to the delalloc handler. This allows the delalloc handler to do complex things
such as cleaning the pages, marking them writeback and starting IO on their
behalf.
* Inline extents are inserted at delalloc time now. This allows us to compress
the data before inserting the inline extent, and it allows us to insert
an inline extent that spans multiple pages.
* All of the in-memory extent representations (extent_map.c, ordered-data.c etc)
are changed to record both an in-memory size and an on disk size, as well
as a flag for compression.
From a disk format point of view, the extent pointers in the file are changed
to record the on disk size of a given extent and some encoding flags.
Space in the disk format is allocated for compression encoding, as well
as encryption and a generic 'other' field. Neither the encryption or the
'other' field are currently used.
In order to limit the amount of data read for a single random read in the
file, the size of a compressed extent is limited to 128k. This is a
software only limit, the disk format supports u64 sized compressed extents.
In order to limit the ram consumed while processing extents, the uncompressed
size of a compressed extent is limited to 256k. This is a software only limit
and will be subject to tuning later.
Checksumming is still done on compressed extents, and it is done on the
uncompressed version of the data. This way additional encodings can be
layered on without having to figure out which encoding to checksum.
Compression happens at delalloc time, which is basically singled threaded because
it is usually done by a single pdflush thread. This makes it tricky to
spread the compression load across all the cpus on the box. We'll have to
look at parallel pdflush walks of dirty inodes at a later time.
Decompression is hooked into readpages and it does spread across CPUs nicely.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2008-10-29 21:49:59 +03:00
|
|
|
}
|
2008-07-17 20:53:50 +04:00
|
|
|
}
|
2008-01-15 16:40:48 +03:00
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* Used to wait on ordered extents across a large range of bytes.
|
|
|
|
*/
|
2013-10-26 00:13:35 +04:00
|
|
|
int btrfs_wait_ordered_range(struct inode *inode, u64 start, u64 len)
|
2008-07-17 20:53:50 +04:00
|
|
|
{
|
2013-10-26 00:13:35 +04:00
|
|
|
int ret = 0;
|
2015-05-05 21:03:10 +03:00
|
|
|
int ret_wb = 0;
|
2008-07-17 20:53:50 +04:00
|
|
|
u64 end;
|
2008-07-19 04:42:20 +04:00
|
|
|
u64 orig_end;
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_extent *ordered;
|
2008-07-19 04:42:20 +04:00
|
|
|
|
|
|
|
if (start + len < start) {
|
2008-07-22 19:18:09 +04:00
|
|
|
orig_end = INT_LIMIT(loff_t);
|
2008-07-19 04:42:20 +04:00
|
|
|
} else {
|
|
|
|
orig_end = start + len - 1;
|
2008-07-22 19:18:09 +04:00
|
|
|
if (orig_end > INT_LIMIT(loff_t))
|
|
|
|
orig_end = INT_LIMIT(loff_t);
|
2008-07-19 04:42:20 +04:00
|
|
|
}
|
2012-04-23 22:41:09 +04:00
|
|
|
|
2008-07-19 04:42:20 +04:00
|
|
|
/* start IO across the range first to instantiate any delalloc
|
|
|
|
* extents
|
|
|
|
*/
|
2014-10-10 12:43:11 +04:00
|
|
|
ret = btrfs_fdatawrite_range(inode, start, orig_end);
|
2013-10-26 00:13:35 +04:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2014-10-10 12:43:11 +04:00
|
|
|
|
2015-05-05 21:03:10 +03:00
|
|
|
/*
|
|
|
|
* If we have a writeback error don't return immediately. Wait first
|
|
|
|
* for any ordered extents that haven't completed yet. This is to make
|
|
|
|
* sure no one can dirty the same page ranges and call writepages()
|
|
|
|
* before the ordered extents complete - to avoid failures (-EEXIST)
|
|
|
|
* when adding the new ordered extents to the ordered tree.
|
|
|
|
*/
|
|
|
|
ret_wb = filemap_fdatawait_range(inode->i_mapping, start, orig_end);
|
2008-07-19 04:42:20 +04:00
|
|
|
|
2008-07-22 19:18:09 +04:00
|
|
|
end = orig_end;
|
2009-01-06 05:25:51 +03:00
|
|
|
while (1) {
|
2020-08-31 14:42:39 +03:00
|
|
|
ordered = btrfs_lookup_first_ordered_extent(BTRFS_I(inode), end);
|
2009-01-06 05:25:51 +03:00
|
|
|
if (!ordered)
|
2008-07-17 20:53:50 +04:00
|
|
|
break;
|
2008-07-19 04:42:20 +04:00
|
|
|
if (ordered->file_offset > orig_end) {
|
2008-07-17 20:53:50 +04:00
|
|
|
btrfs_put_ordered_extent(ordered);
|
|
|
|
break;
|
|
|
|
}
|
2019-12-03 04:34:19 +03:00
|
|
|
if (ordered->file_offset + ordered->num_bytes <= start) {
|
2008-07-17 20:53:50 +04:00
|
|
|
btrfs_put_ordered_extent(ordered);
|
|
|
|
break;
|
|
|
|
}
|
2020-09-18 12:15:53 +03:00
|
|
|
btrfs_start_ordered_extent(ordered, 1);
|
2008-07-17 20:53:50 +04:00
|
|
|
end = ordered->file_offset;
|
2020-02-13 15:29:50 +03:00
|
|
|
/*
|
|
|
|
* If the ordered extent had an error save the error but don't
|
|
|
|
* exit without waiting first for all other ordered extents in
|
|
|
|
* the range to complete.
|
|
|
|
*/
|
2013-10-26 00:13:35 +04:00
|
|
|
if (test_bit(BTRFS_ORDERED_IOERR, &ordered->flags))
|
|
|
|
ret = -EIO;
|
2008-07-17 20:53:50 +04:00
|
|
|
btrfs_put_ordered_extent(ordered);
|
2020-02-13 15:29:50 +03:00
|
|
|
if (end == 0 || end == start)
|
2008-07-17 20:53:50 +04:00
|
|
|
break;
|
|
|
|
end--;
|
|
|
|
}
|
2015-05-05 21:03:10 +03:00
|
|
|
return ret_wb ? ret_wb : ret;
|
2008-01-15 16:40:48 +03:00
|
|
|
}
|
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* find an ordered extent corresponding to file_offset. return NULL if
|
|
|
|
* nothing is found, otherwise take a reference on the extent and return it
|
|
|
|
*/
|
2020-06-03 08:55:03 +03:00
|
|
|
struct btrfs_ordered_extent *btrfs_lookup_ordered_extent(struct btrfs_inode *inode,
|
2008-07-17 20:53:50 +04:00
|
|
|
u64 file_offset)
|
|
|
|
{
|
|
|
|
struct btrfs_ordered_inode_tree *tree;
|
|
|
|
struct rb_node *node;
|
|
|
|
struct btrfs_ordered_extent *entry = NULL;
|
|
|
|
|
2020-06-03 08:55:03 +03:00
|
|
|
tree = &inode->ordered_tree;
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
node = tree_search(tree, file_offset);
|
|
|
|
if (!node)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
entry = rb_entry(node, struct btrfs_ordered_extent, rb_node);
|
|
|
|
if (!offset_in_entry(entry, file_offset))
|
|
|
|
entry = NULL;
|
|
|
|
if (entry)
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&entry->refs);
|
2008-07-17 20:53:50 +04:00
|
|
|
out:
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
2010-05-23 19:00:55 +04:00
|
|
|
/* Since the DIO code tries to lock a wide area we need to look for any ordered
|
|
|
|
* extents that exist in the range, rather than just the start of the range.
|
|
|
|
*/
|
2017-02-20 14:50:49 +03:00
|
|
|
struct btrfs_ordered_extent *btrfs_lookup_ordered_range(
|
|
|
|
struct btrfs_inode *inode, u64 file_offset, u64 len)
|
2010-05-23 19:00:55 +04:00
|
|
|
{
|
|
|
|
struct btrfs_ordered_inode_tree *tree;
|
|
|
|
struct rb_node *node;
|
|
|
|
struct btrfs_ordered_extent *entry = NULL;
|
|
|
|
|
2017-02-20 14:50:49 +03:00
|
|
|
tree = &inode->ordered_tree;
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2010-05-23 19:00:55 +04:00
|
|
|
node = tree_search(tree, file_offset);
|
|
|
|
if (!node) {
|
|
|
|
node = tree_search(tree, file_offset + len);
|
|
|
|
if (!node)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
entry = rb_entry(node, struct btrfs_ordered_extent, rb_node);
|
|
|
|
if (range_overlaps(entry, file_offset, len))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (entry->file_offset >= file_offset + len) {
|
|
|
|
entry = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
entry = NULL;
|
|
|
|
node = rb_next(node);
|
|
|
|
if (!node)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
if (entry)
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&entry->refs);
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2010-05-23 19:00:55 +04:00
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
btrfs: make fast fsyncs wait only for writeback
Currently regardless of a full or a fast fsync we always wait for ordered
extents to complete, and then start logging the inode after that. However
for fast fsyncs we can just wait for the writeback to complete, we don't
need to wait for the ordered extents to complete since we use the list of
modified extents maps to figure out which extents we must log and we can
get their checksums directly from the ordered extents that are still in
flight, otherwise look them up from the checksums tree.
Until commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at
fsync time"), for fast fsyncs, we used to start logging without even
waiting for the writeback to complete first, we would wait for it to
complete after logging, while holding a transaction open, which lead to
performance issues when using cgroups and probably for other cases too,
as wait for IO while holding a transaction handle should be avoided as
much as possible. After that, for fast fsyncs, we started to wait for
ordered extents to complete before starting to log, which adds some
latency to fsyncs and we even got at least one report about a performance
drop which bisected to that particular change:
https://lore.kernel.org/linux-btrfs/20181109215148.GF23260@techsingularity.net/
This change makes fast fsyncs only wait for writeback to finish before
starting to log the inode, instead of waiting for both the writeback to
finish and for the ordered extents to complete. This brings back part of
the logic we had that extracts checksums from in flight ordered extents,
which are not yet in the checksums tree, and making sure transaction
commits wait for the completion of ordered extents previously logged
(by far most of the time they have already completed by the time a
transaction commit starts, resulting in no wait at all), to avoid any
data loss if an ordered extent completes after the transaction used to
log an inode is committed, followed by a power failure.
When there are no other tasks accessing the checksums and the subvolume
btrees, the ordered extent completion is pretty fast, typically taking
100 to 200 microseconds only in my observations. However when there are
other tasks accessing these btrees, ordered extent completion can take a
lot more time due to lock contention on nodes and leaves of these btrees.
I've seen cases over 2 milliseconds, which starts to be significant. In
particular when we do have concurrent fsyncs against different files there
is a lot of contention on the checksums btree, since we have many tasks
writing the checksums into the btree and other tasks that already started
the logging phase are doing lookups for checksums in the btree.
This change also turns all ranged fsyncs into full ranged fsyncs, which
is something we already did when not using the NO_HOLES features or when
doing a full fsync. This is to guarantee we never miss checksums due to
writeback having been triggered only for a part of an extent, and we end
up logging the full extent but only checksums for the written range, which
results in missing checksums after log replay. Allowing ranged fsyncs to
operate again only in the original range, when using the NO_HOLES feature
and doing a fast fsync is doable but requires some non trivial changes to
the writeback path, which can always be worked on later if needed, but I
don't think they are a very common use case.
Several tests were performed using fio for different numbers of concurrent
jobs, each writing and fsyncing its own file, for both sequential and
random file writes. The tests were run on bare metal, no virtualization,
on a box with 12 cores (Intel i7-8700), 64Gb of RAM and a NVMe device,
with a kernel configuration that is the default of typical distributions
(debian in this case), without debug options enabled (kasan, kmemleak,
slub debug, debug of page allocations, lock debugging, etc).
The following script that calls fio was used:
$ cat test-fsync.sh
#!/bin/bash
DEV=/dev/nvme0n1
MNT=/mnt/btrfs
MOUNT_OPTIONS="-o ssd -o space_cache=v2"
MKFS_OPTIONS="-d single -m single"
if [ $# -ne 5 ]; then
echo "Use $0 NUM_JOBS FILE_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]"
exit 1
fi
NUM_JOBS=$1
FILE_SIZE=$2
FSYNC_FREQ=$3
BLOCK_SIZE=$4
WRITE_MODE=$5
if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then
echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'"
exit 1
fi
cat <<EOF > /tmp/fio-job.ini
[writers]
rw=$WRITE_MODE
fsync=$FSYNC_FREQ
fallocate=none
group_reporting=1
direct=0
bs=$BLOCK_SIZE
ioengine=sync
size=$FILE_SIZE
directory=$MNT
numjobs=$NUM_JOBS
EOF
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo
echo "Using config:"
echo
cat /tmp/fio-job.ini
echo
umount $MNT &> /dev/null
mkfs.btrfs -f $MKFS_OPTIONS $DEV
mount $MOUNT_OPTIONS $DEV $MNT
fio /tmp/fio-job.ini
umount $MNT
The results were the following:
*************************
*** sequential writes ***
*************************
==== 1 job, 8GiB file, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=8192MiB (8590MB), run=223689-223689msec
After patch:
WRITE: bw=40.2MiB/s (42.1MB/s), 40.2MiB/s-40.2MiB/s (42.1MB/s-42.1MB/s), io=8192MiB (8590MB), run=203980-203980msec
(+9.8%, -8.8% runtime)
==== 2 jobs, 4GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=8192MiB (8590MB), run=228950-228950msec
After patch:
WRITE: bw=43.5MiB/s (45.6MB/s), 43.5MiB/s-43.5MiB/s (45.6MB/s-45.6MB/s), io=8192MiB (8590MB), run=188272-188272msec
(+21.5% throughput, -17.8% runtime)
==== 4 jobs, 2GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=50.1MiB/s (52.6MB/s), 50.1MiB/s-50.1MiB/s (52.6MB/s-52.6MB/s), io=8192MiB (8590MB), run=163446-163446msec
After patch:
WRITE: bw=64.5MiB/s (67.6MB/s), 64.5MiB/s-64.5MiB/s (67.6MB/s-67.6MB/s), io=8192MiB (8590MB), run=126987-126987msec
(+28.7% throughput, -22.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=64.0MiB/s (68.1MB/s), 64.0MiB/s-64.0MiB/s (68.1MB/s-68.1MB/s), io=8192MiB (8590MB), run=126075-126075msec
After patch:
WRITE: bw=86.8MiB/s (91.0MB/s), 86.8MiB/s-86.8MiB/s (91.0MB/s-91.0MB/s), io=8192MiB (8590MB), run=94358-94358msec
(+35.6% throughput, -25.2% runtime)
==== 16 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=79.8MiB/s (83.6MB/s), 79.8MiB/s-79.8MiB/s (83.6MB/s-83.6MB/s), io=8192MiB (8590MB), run=102694-102694msec
After patch:
WRITE: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=8192MiB (8590MB), run=76446-76446msec
(+34.1% throughput, -25.6% runtime)
==== 32 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=93.2MiB/s (97.7MB/s), 93.2MiB/s-93.2MiB/s (97.7MB/s-97.7MB/s), io=16.0GiB (17.2GB), run=175836-175836msec
After patch:
WRITE: bw=111MiB/s (117MB/s), 111MiB/s-111MiB/s (117MB/s-117MB/s), io=16.0GiB (17.2GB), run=147001-147001msec
(+19.1% throughput, -16.4% runtime)
==== 64 jobs, 512MiB files, fsync frequency 1, block size 64KiB ====
Before patch:
WRITE: bw=108MiB/s (114MB/s), 108MiB/s-108MiB/s (114MB/s-114MB/s), io=32.0GiB (34.4GB), run=302656-302656msec
After patch:
WRITE: bw=133MiB/s (140MB/s), 133MiB/s-133MiB/s (140MB/s-140MB/s), io=32.0GiB (34.4GB), run=246003-246003msec
(+23.1% throughput, -18.7% runtime)
************************
*** random writes ***
************************
==== 1 job, 8GiB file, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=11.5MiB/s (12.0MB/s), 11.5MiB/s-11.5MiB/s (12.0MB/s-12.0MB/s), io=8192MiB (8590MB), run=714281-714281msec
After patch:
WRITE: bw=11.6MiB/s (12.2MB/s), 11.6MiB/s-11.6MiB/s (12.2MB/s-12.2MB/s), io=8192MiB (8590MB), run=705959-705959msec
(+0.9% throughput, -1.7% runtime)
==== 2 jobs, 4GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=12.8MiB/s (13.5MB/s), 12.8MiB/s-12.8MiB/s (13.5MB/s-13.5MB/s), io=8192MiB (8590MB), run=638101-638101msec
After patch:
WRITE: bw=13.1MiB/s (13.7MB/s), 13.1MiB/s-13.1MiB/s (13.7MB/s-13.7MB/s), io=8192MiB (8590MB), run=625374-625374msec
(+2.3% throughput, -2.0% runtime)
==== 4 jobs, 2GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=15.4MiB/s (16.2MB/s), 15.4MiB/s-15.4MiB/s (16.2MB/s-16.2MB/s), io=8192MiB (8590MB), run=531146-531146msec
After patch:
WRITE: bw=17.8MiB/s (18.7MB/s), 17.8MiB/s-17.8MiB/s (18.7MB/s-18.7MB/s), io=8192MiB (8590MB), run=460431-460431msec
(+15.6% throughput, -13.3% runtime)
==== 8 jobs, 1GiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=19.9MiB/s (20.8MB/s), 19.9MiB/s-19.9MiB/s (20.8MB/s-20.8MB/s), io=8192MiB (8590MB), run=412664-412664msec
After patch:
WRITE: bw=22.2MiB/s (23.3MB/s), 22.2MiB/s-22.2MiB/s (23.3MB/s-23.3MB/s), io=8192MiB (8590MB), run=368589-368589msec
(+11.6% throughput, -10.7% runtime)
==== 16 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=29.3MiB/s (30.7MB/s), 29.3MiB/s-29.3MiB/s (30.7MB/s-30.7MB/s), io=8192MiB (8590MB), run=279924-279924msec
After patch:
WRITE: bw=30.4MiB/s (31.9MB/s), 30.4MiB/s-30.4MiB/s (31.9MB/s-31.9MB/s), io=8192MiB (8590MB), run=269258-269258msec
(+3.8% throughput, -3.8% runtime)
==== 32 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=36.9MiB/s (38.7MB/s), 36.9MiB/s-36.9MiB/s (38.7MB/s-38.7MB/s), io=16.0GiB (17.2GB), run=443581-443581msec
After patch:
WRITE: bw=41.6MiB/s (43.6MB/s), 41.6MiB/s-41.6MiB/s (43.6MB/s-43.6MB/s), io=16.0GiB (17.2GB), run=394114-394114msec
(+12.7% throughput, -11.2% runtime)
==== 64 jobs, 512MiB files, fsync frequency 16, block size 4KiB ====
Before patch:
WRITE: bw=45.9MiB/s (48.1MB/s), 45.9MiB/s-45.9MiB/s (48.1MB/s-48.1MB/s), io=32.0GiB (34.4GB), run=714614-714614msec
After patch:
WRITE: bw=48.8MiB/s (51.1MB/s), 48.8MiB/s-48.8MiB/s (51.1MB/s-51.1MB/s), io=32.0GiB (34.4GB), run=672087-672087msec
(+6.3% throughput, -6.0% runtime)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-08-11 14:43:58 +03:00
|
|
|
/*
|
|
|
|
* Adds all ordered extents to the given list. The list ends up sorted by the
|
|
|
|
* file_offset of the ordered extents.
|
|
|
|
*/
|
|
|
|
void btrfs_get_ordered_extents_for_logging(struct btrfs_inode *inode,
|
|
|
|
struct list_head *list)
|
|
|
|
{
|
|
|
|
struct btrfs_ordered_inode_tree *tree = &inode->ordered_tree;
|
|
|
|
struct rb_node *n;
|
|
|
|
|
|
|
|
ASSERT(inode_is_locked(&inode->vfs_inode));
|
|
|
|
|
|
|
|
spin_lock_irq(&tree->lock);
|
|
|
|
for (n = rb_first(&tree->tree); n; n = rb_next(n)) {
|
|
|
|
struct btrfs_ordered_extent *ordered;
|
|
|
|
|
|
|
|
ordered = rb_entry(n, struct btrfs_ordered_extent, rb_node);
|
|
|
|
|
|
|
|
if (test_bit(BTRFS_ORDERED_LOGGED, &ordered->flags))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ASSERT(list_empty(&ordered->log_list));
|
|
|
|
list_add_tail(&ordered->log_list, list);
|
|
|
|
refcount_inc(&ordered->refs);
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&tree->lock);
|
|
|
|
}
|
|
|
|
|
2008-07-17 21:53:27 +04:00
|
|
|
/*
|
|
|
|
* lookup and return any extent before 'file_offset'. NULL is returned
|
|
|
|
* if none is found
|
|
|
|
*/
|
2008-07-17 20:53:50 +04:00
|
|
|
struct btrfs_ordered_extent *
|
2020-08-31 14:42:39 +03:00
|
|
|
btrfs_lookup_first_ordered_extent(struct btrfs_inode *inode, u64 file_offset)
|
2008-07-17 20:53:50 +04:00
|
|
|
{
|
|
|
|
struct btrfs_ordered_inode_tree *tree;
|
|
|
|
struct rb_node *node;
|
|
|
|
struct btrfs_ordered_extent *entry = NULL;
|
|
|
|
|
2020-08-31 14:42:39 +03:00
|
|
|
tree = &inode->ordered_tree;
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_lock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
node = tree_search(tree, file_offset);
|
|
|
|
if (!node)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
entry = rb_entry(node, struct btrfs_ordered_extent, rb_node);
|
2017-03-03 11:55:13 +03:00
|
|
|
refcount_inc(&entry->refs);
|
2008-07-17 20:53:50 +04:00
|
|
|
out:
|
2012-05-02 22:00:54 +04:00
|
|
|
spin_unlock_irq(&tree->lock);
|
2008-07-17 20:53:50 +04:00
|
|
|
return entry;
|
2008-04-25 16:51:48 +04:00
|
|
|
}
|
2008-07-17 20:54:05 +04:00
|
|
|
|
2019-05-07 10:19:22 +03:00
|
|
|
/*
|
|
|
|
* btrfs_flush_ordered_range - Lock the passed range and ensures all pending
|
|
|
|
* ordered extents in it are run to completion.
|
|
|
|
*
|
|
|
|
* @inode: Inode whose ordered tree is to be searched
|
|
|
|
* @start: Beginning of range to flush
|
|
|
|
* @end: Last byte of range to lock
|
|
|
|
* @cached_state: If passed, will return the extent state responsible for the
|
|
|
|
* locked range. It's the caller's responsibility to free the cached state.
|
|
|
|
*
|
|
|
|
* This function always returns with the given range locked, ensuring after it's
|
|
|
|
* called no order extent can be pending.
|
|
|
|
*/
|
2020-02-05 21:09:33 +03:00
|
|
|
void btrfs_lock_and_flush_ordered_range(struct btrfs_inode *inode, u64 start,
|
2019-05-07 10:19:22 +03:00
|
|
|
u64 end,
|
|
|
|
struct extent_state **cached_state)
|
|
|
|
{
|
|
|
|
struct btrfs_ordered_extent *ordered;
|
2019-07-26 10:47:05 +03:00
|
|
|
struct extent_state *cache = NULL;
|
|
|
|
struct extent_state **cachedp = &cache;
|
2019-05-07 10:19:24 +03:00
|
|
|
|
|
|
|
if (cached_state)
|
2019-07-26 10:47:05 +03:00
|
|
|
cachedp = cached_state;
|
2019-05-07 10:19:22 +03:00
|
|
|
|
|
|
|
while (1) {
|
2020-02-05 21:09:33 +03:00
|
|
|
lock_extent_bits(&inode->io_tree, start, end, cachedp);
|
2019-05-07 10:19:22 +03:00
|
|
|
ordered = btrfs_lookup_ordered_range(inode, start,
|
|
|
|
end - start + 1);
|
2019-05-07 10:19:24 +03:00
|
|
|
if (!ordered) {
|
|
|
|
/*
|
|
|
|
* If no external cached_state has been passed then
|
|
|
|
* decrement the extra ref taken for cachedp since we
|
|
|
|
* aren't exposing it outside of this function
|
|
|
|
*/
|
|
|
|
if (!cached_state)
|
2019-07-26 10:47:05 +03:00
|
|
|
refcount_dec(&cache->refs);
|
2019-05-07 10:19:22 +03:00
|
|
|
break;
|
2019-05-07 10:19:24 +03:00
|
|
|
}
|
2020-02-05 21:09:33 +03:00
|
|
|
unlock_extent_cached(&inode->io_tree, start, end, cachedp);
|
2020-09-18 12:15:53 +03:00
|
|
|
btrfs_start_ordered_extent(ordered, 1);
|
2019-05-07 10:19:22 +03:00
|
|
|
btrfs_put_ordered_extent(ordered);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-06 14:01:51 +04:00
|
|
|
int __init ordered_data_init(void)
|
|
|
|
{
|
|
|
|
btrfs_ordered_extent_cache = kmem_cache_create("btrfs_ordered_extent",
|
|
|
|
sizeof(struct btrfs_ordered_extent), 0,
|
2016-06-23 21:17:08 +03:00
|
|
|
SLAB_MEM_SPREAD,
|
2012-09-06 14:01:51 +04:00
|
|
|
NULL);
|
|
|
|
if (!btrfs_ordered_extent_cache)
|
|
|
|
return -ENOMEM;
|
2012-10-25 13:31:03 +04:00
|
|
|
|
2012-09-06 14:01:51 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-19 19:24:18 +03:00
|
|
|
void __cold ordered_data_exit(void)
|
2012-09-06 14:01:51 +04:00
|
|
|
{
|
2016-01-29 16:36:35 +03:00
|
|
|
kmem_cache_destroy(btrfs_ordered_extent_cache);
|
2012-09-06 14:01:51 +04:00
|
|
|
}
|