2018-04-04 01:23:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2007-06-12 21:07:21 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2007 Oracle. All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2007-03-23 03:59:16 +08:00
|
|
|
#include <linux/fs.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2007-06-12 23:36:58 +08:00
|
|
|
#include <linux/sched.h>
|
2007-09-17 22:58:06 +08:00
|
|
|
#include <linux/writeback.h>
|
2007-10-16 04:14:19 +08:00
|
|
|
#include <linux/pagemap.h>
|
2008-11-08 07:22:45 +08:00
|
|
|
#include <linux/blkdev.h>
|
2012-07-25 23:35:53 +08:00
|
|
|
#include <linux/uuid.h>
|
2019-08-22 00:48:25 +08:00
|
|
|
#include "misc.h"
|
2007-03-23 03:59:16 +08:00
|
|
|
#include "ctree.h"
|
|
|
|
#include "disk-io.h"
|
|
|
|
#include "transaction.h"
|
2008-06-26 04:01:30 +08:00
|
|
|
#include "locking.h"
|
2008-09-06 04:13:11 +08:00
|
|
|
#include "tree-log.h"
|
Btrfs: Cache free inode numbers in memory
Currently btrfs stores the highest objectid of the fs tree, and it always
returns (highest+1) inode number when we create a file, so inode numbers
won't be reclaimed when we delete files, so we'll run out of inode numbers
as we keep create/delete files in 32bits machines.
This fixes it, and it works similarly to how we cache free space in block
cgroups.
We start a kernel thread to read the file tree. By scanning inode items,
we know which chunks of inode numbers are free, and we cache them in
an rb-tree.
Because we are searching the commit root, we have to carefully handle the
cross-transaction case.
The rb-tree is a hybrid extent+bitmap tree, so if we have too many small
chunks of inode numbers, we'll use bitmaps. Initially we allow 16K ram
of extents, and a bitmap will be used if we exceed this threshold. The
extents threshold is adjusted in runtime.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
2011-04-20 10:06:11 +08:00
|
|
|
#include "inode-map.h"
|
2012-05-25 22:06:10 +08:00
|
|
|
#include "volumes.h"
|
2012-11-06 20:15:27 +08:00
|
|
|
#include "dev-replace.h"
|
2014-05-14 08:30:47 +08:00
|
|
|
#include "qgroup.h"
|
2019-06-21 03:37:44 +08:00
|
|
|
#include "block-group.h"
|
2020-03-14 03:28:48 +08:00
|
|
|
#include "space-info.h"
|
2007-03-23 03:59:16 +08:00
|
|
|
|
2007-04-09 22:42:37 +08:00
|
|
|
#define BTRFS_ROOT_TRANS_TAG 0
|
|
|
|
|
2019-08-22 15:24:59 +08:00
|
|
|
/*
|
|
|
|
* Transaction states and transitions
|
|
|
|
*
|
|
|
|
* No running transaction (fs tree blocks are not modified)
|
|
|
|
* |
|
|
|
|
* | To next stage:
|
|
|
|
* | Call start_transaction() variants. Except btrfs_join_transaction_nostart().
|
|
|
|
* V
|
|
|
|
* Transaction N [[TRANS_STATE_RUNNING]]
|
|
|
|
* |
|
|
|
|
* | New trans handles can be attached to transaction N by calling all
|
|
|
|
* | start_transaction() variants.
|
|
|
|
* |
|
|
|
|
* | To next stage:
|
|
|
|
* | Call btrfs_commit_transaction() on any trans handle attached to
|
|
|
|
* | transaction N
|
|
|
|
* V
|
|
|
|
* Transaction N [[TRANS_STATE_COMMIT_START]]
|
|
|
|
* |
|
|
|
|
* | Will wait for previous running transaction to completely finish if there
|
|
|
|
* | is one
|
|
|
|
* |
|
|
|
|
* | Then one of the following happes:
|
|
|
|
* | - Wait for all other trans handle holders to release.
|
|
|
|
* | The btrfs_commit_transaction() caller will do the commit work.
|
|
|
|
* | - Wait for current transaction to be committed by others.
|
|
|
|
* | Other btrfs_commit_transaction() caller will do the commit work.
|
|
|
|
* |
|
|
|
|
* | At this stage, only btrfs_join_transaction*() variants can attach
|
|
|
|
* | to this running transaction.
|
|
|
|
* | All other variants will wait for current one to finish and attach to
|
|
|
|
* | transaction N+1.
|
|
|
|
* |
|
|
|
|
* | To next stage:
|
|
|
|
* | Caller is chosen to commit transaction N, and all other trans handle
|
|
|
|
* | haven been released.
|
|
|
|
* V
|
|
|
|
* Transaction N [[TRANS_STATE_COMMIT_DOING]]
|
|
|
|
* |
|
|
|
|
* | The heavy lifting transaction work is started.
|
|
|
|
* | From running delayed refs (modifying extent tree) to creating pending
|
|
|
|
* | snapshots, running qgroups.
|
|
|
|
* | In short, modify supporting trees to reflect modifications of subvolume
|
|
|
|
* | trees.
|
|
|
|
* |
|
|
|
|
* | At this stage, all start_transaction() calls will wait for this
|
|
|
|
* | transaction to finish and attach to transaction N+1.
|
|
|
|
* |
|
|
|
|
* | To next stage:
|
|
|
|
* | Until all supporting trees are updated.
|
|
|
|
* V
|
|
|
|
* Transaction N [[TRANS_STATE_UNBLOCKED]]
|
|
|
|
* | Transaction N+1
|
|
|
|
* | All needed trees are modified, thus we only [[TRANS_STATE_RUNNING]]
|
|
|
|
* | need to write them back to disk and update |
|
|
|
|
* | super blocks. |
|
|
|
|
* | |
|
|
|
|
* | At this stage, new transaction is allowed to |
|
|
|
|
* | start. |
|
|
|
|
* | All new start_transaction() calls will be |
|
|
|
|
* | attached to transid N+1. |
|
|
|
|
* | |
|
|
|
|
* | To next stage: |
|
|
|
|
* | Until all tree blocks are super blocks are |
|
|
|
|
* | written to block devices |
|
|
|
|
* V |
|
|
|
|
* Transaction N [[TRANS_STATE_COMPLETED]] V
|
|
|
|
* All tree blocks and super blocks are written. Transaction N+1
|
|
|
|
* This transaction is finished and all its [[TRANS_STATE_COMMIT_START]]
|
|
|
|
* data structures will be cleaned up. | Life goes on
|
|
|
|
*/
|
2015-01-03 01:23:10 +08:00
|
|
|
static const unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
[TRANS_STATE_RUNNING] = 0U,
|
2018-02-05 16:41:15 +08:00
|
|
|
[TRANS_STATE_COMMIT_START] = (__TRANS_START | __TRANS_ATTACH),
|
|
|
|
[TRANS_STATE_COMMIT_DOING] = (__TRANS_START |
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
__TRANS_ATTACH |
|
Btrfs: fix deadlock between fiemap and transaction commits
The fiemap handler locks a file range that can have unflushed delalloc,
and after locking the range, it tries to attach to a running transaction.
If the running transaction started its commit, that is, it is in state
TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
flushoncommit option or the transaction is creating a snapshot for the
subvolume that contains the file that fiemap is operating on, we end up
deadlocking. This happens because fiemap is blocked on the transaction,
waiting for it to complete, and the transaction is waiting for the flushed
dealloc to complete, which requires locking the file range that the fiemap
task already locked. The following stack traces serve as an example of
when this deadlock happens:
(...)
[404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[404571.515956] Call Trace:
[404571.516360] ? __schedule+0x3ae/0x7b0
[404571.516730] schedule+0x3a/0xb0
[404571.517104] lock_extent_bits+0x1ec/0x2a0 [btrfs]
[404571.517465] ? remove_wait_queue+0x60/0x60
[404571.517832] btrfs_finish_ordered_io+0x292/0x800 [btrfs]
[404571.518202] normal_work_helper+0xea/0x530 [btrfs]
[404571.518566] process_one_work+0x21e/0x5c0
[404571.518990] worker_thread+0x4f/0x3b0
[404571.519413] ? process_one_work+0x5c0/0x5c0
[404571.519829] kthread+0x103/0x140
[404571.520191] ? kthread_create_worker_on_cpu+0x70/0x70
[404571.520565] ret_from_fork+0x3a/0x50
[404571.520915] kworker/u8:6 D 0 31651 2 0x80004000
[404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
(...)
[404571.537000] fsstress D 0 13117 13115 0x00004000
[404571.537263] Call Trace:
[404571.537524] ? __schedule+0x3ae/0x7b0
[404571.537788] schedule+0x3a/0xb0
[404571.538066] wait_current_trans+0xc8/0x100 [btrfs]
[404571.538349] ? remove_wait_queue+0x60/0x60
[404571.538680] start_transaction+0x33c/0x500 [btrfs]
[404571.539076] btrfs_check_shared+0xa3/0x1f0 [btrfs]
[404571.539513] ? extent_fiemap+0x2ce/0x650 [btrfs]
[404571.539866] extent_fiemap+0x2ce/0x650 [btrfs]
[404571.540170] do_vfs_ioctl+0x526/0x6f0
[404571.540436] ksys_ioctl+0x70/0x80
[404571.540734] __x64_sys_ioctl+0x16/0x20
[404571.540997] do_syscall_64+0x60/0x1d0
[404571.541279] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
[404571.543729] btrfs D 0 14210 14208 0x00004000
[404571.544023] Call Trace:
[404571.544275] ? __schedule+0x3ae/0x7b0
[404571.544526] ? wait_for_completion+0x112/0x1a0
[404571.544795] schedule+0x3a/0xb0
[404571.545064] schedule_timeout+0x1ff/0x390
[404571.545351] ? lock_acquire+0xa6/0x190
[404571.545638] ? wait_for_completion+0x49/0x1a0
[404571.545890] ? wait_for_completion+0x112/0x1a0
[404571.546228] wait_for_completion+0x131/0x1a0
[404571.546503] ? wake_up_q+0x70/0x70
[404571.546775] btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
[404571.547159] btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
[404571.547449] ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
[404571.547703] ? remove_wait_queue+0x60/0x60
[404571.547969] btrfs_mksubvol+0x605/0x640 [btrfs]
[404571.548226] ? __sb_start_write+0xd4/0x1c0
[404571.548512] ? mnt_want_write_file+0x24/0x50
[404571.548789] btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
[404571.549048] btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
[404571.549307] btrfs_ioctl+0x133f/0x3150 [btrfs]
[404571.549549] ? mem_cgroup_charge_statistics+0x4c/0xd0
[404571.549792] ? mem_cgroup_commit_charge+0x84/0x4b0
[404571.550064] ? __handle_mm_fault+0xe3e/0x11f0
[404571.550306] ? do_raw_spin_unlock+0x49/0xc0
[404571.550608] ? _raw_spin_unlock+0x24/0x30
[404571.550976] ? __handle_mm_fault+0xedf/0x11f0
[404571.551319] ? do_vfs_ioctl+0xa2/0x6f0
[404571.551659] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[404571.552087] do_vfs_ioctl+0xa2/0x6f0
[404571.552355] ksys_ioctl+0x70/0x80
[404571.552621] __x64_sys_ioctl+0x16/0x20
[404571.552864] do_syscall_64+0x60/0x1d0
[404571.553104] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
If we were joining the transaction instead of attaching to it, we would
not risk a deadlock because a join only blocks if the transaction is in a
state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
flush performed by a transaction is done before it reaches that state,
when it is in the state TRANS_STATE_COMMIT_START. However a transaction
join is intended for use cases where we do modify the filesystem, and
fiemap only needs to peek at delayed references from the current
transaction in order to determine if extents are shared, and, besides
that, when there is no current transaction or when it blocks to wait for
a current committing transaction to complete, it creates a new transaction
without reserving any space. Such unnecessary transactions, besides doing
unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
rotation of the precious backup roots.
So fix this by adding a new transaction join variant, named join_nostart,
which behaves like the regular join, but it does not create a transaction
when none currently exists or after waiting for a committing transaction
to complete.
Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-29 16:37:10 +08:00
|
|
|
__TRANS_JOIN |
|
|
|
|
__TRANS_JOIN_NOSTART),
|
2018-02-05 16:41:15 +08:00
|
|
|
[TRANS_STATE_UNBLOCKED] = (__TRANS_START |
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
__TRANS_ATTACH |
|
|
|
|
__TRANS_JOIN |
|
Btrfs: fix deadlock between fiemap and transaction commits
The fiemap handler locks a file range that can have unflushed delalloc,
and after locking the range, it tries to attach to a running transaction.
If the running transaction started its commit, that is, it is in state
TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
flushoncommit option or the transaction is creating a snapshot for the
subvolume that contains the file that fiemap is operating on, we end up
deadlocking. This happens because fiemap is blocked on the transaction,
waiting for it to complete, and the transaction is waiting for the flushed
dealloc to complete, which requires locking the file range that the fiemap
task already locked. The following stack traces serve as an example of
when this deadlock happens:
(...)
[404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[404571.515956] Call Trace:
[404571.516360] ? __schedule+0x3ae/0x7b0
[404571.516730] schedule+0x3a/0xb0
[404571.517104] lock_extent_bits+0x1ec/0x2a0 [btrfs]
[404571.517465] ? remove_wait_queue+0x60/0x60
[404571.517832] btrfs_finish_ordered_io+0x292/0x800 [btrfs]
[404571.518202] normal_work_helper+0xea/0x530 [btrfs]
[404571.518566] process_one_work+0x21e/0x5c0
[404571.518990] worker_thread+0x4f/0x3b0
[404571.519413] ? process_one_work+0x5c0/0x5c0
[404571.519829] kthread+0x103/0x140
[404571.520191] ? kthread_create_worker_on_cpu+0x70/0x70
[404571.520565] ret_from_fork+0x3a/0x50
[404571.520915] kworker/u8:6 D 0 31651 2 0x80004000
[404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
(...)
[404571.537000] fsstress D 0 13117 13115 0x00004000
[404571.537263] Call Trace:
[404571.537524] ? __schedule+0x3ae/0x7b0
[404571.537788] schedule+0x3a/0xb0
[404571.538066] wait_current_trans+0xc8/0x100 [btrfs]
[404571.538349] ? remove_wait_queue+0x60/0x60
[404571.538680] start_transaction+0x33c/0x500 [btrfs]
[404571.539076] btrfs_check_shared+0xa3/0x1f0 [btrfs]
[404571.539513] ? extent_fiemap+0x2ce/0x650 [btrfs]
[404571.539866] extent_fiemap+0x2ce/0x650 [btrfs]
[404571.540170] do_vfs_ioctl+0x526/0x6f0
[404571.540436] ksys_ioctl+0x70/0x80
[404571.540734] __x64_sys_ioctl+0x16/0x20
[404571.540997] do_syscall_64+0x60/0x1d0
[404571.541279] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
[404571.543729] btrfs D 0 14210 14208 0x00004000
[404571.544023] Call Trace:
[404571.544275] ? __schedule+0x3ae/0x7b0
[404571.544526] ? wait_for_completion+0x112/0x1a0
[404571.544795] schedule+0x3a/0xb0
[404571.545064] schedule_timeout+0x1ff/0x390
[404571.545351] ? lock_acquire+0xa6/0x190
[404571.545638] ? wait_for_completion+0x49/0x1a0
[404571.545890] ? wait_for_completion+0x112/0x1a0
[404571.546228] wait_for_completion+0x131/0x1a0
[404571.546503] ? wake_up_q+0x70/0x70
[404571.546775] btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
[404571.547159] btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
[404571.547449] ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
[404571.547703] ? remove_wait_queue+0x60/0x60
[404571.547969] btrfs_mksubvol+0x605/0x640 [btrfs]
[404571.548226] ? __sb_start_write+0xd4/0x1c0
[404571.548512] ? mnt_want_write_file+0x24/0x50
[404571.548789] btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
[404571.549048] btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
[404571.549307] btrfs_ioctl+0x133f/0x3150 [btrfs]
[404571.549549] ? mem_cgroup_charge_statistics+0x4c/0xd0
[404571.549792] ? mem_cgroup_commit_charge+0x84/0x4b0
[404571.550064] ? __handle_mm_fault+0xe3e/0x11f0
[404571.550306] ? do_raw_spin_unlock+0x49/0xc0
[404571.550608] ? _raw_spin_unlock+0x24/0x30
[404571.550976] ? __handle_mm_fault+0xedf/0x11f0
[404571.551319] ? do_vfs_ioctl+0xa2/0x6f0
[404571.551659] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[404571.552087] do_vfs_ioctl+0xa2/0x6f0
[404571.552355] ksys_ioctl+0x70/0x80
[404571.552621] __x64_sys_ioctl+0x16/0x20
[404571.552864] do_syscall_64+0x60/0x1d0
[404571.553104] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
If we were joining the transaction instead of attaching to it, we would
not risk a deadlock because a join only blocks if the transaction is in a
state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
flush performed by a transaction is done before it reaches that state,
when it is in the state TRANS_STATE_COMMIT_START. However a transaction
join is intended for use cases where we do modify the filesystem, and
fiemap only needs to peek at delayed references from the current
transaction in order to determine if extents are shared, and, besides
that, when there is no current transaction or when it blocks to wait for
a current committing transaction to complete, it creates a new transaction
without reserving any space. Such unnecessary transactions, besides doing
unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
rotation of the precious backup roots.
So fix this by adding a new transaction join variant, named join_nostart,
which behaves like the regular join, but it does not create a transaction
when none currently exists or after waiting for a committing transaction
to complete.
Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-29 16:37:10 +08:00
|
|
|
__TRANS_JOIN_NOLOCK |
|
|
|
|
__TRANS_JOIN_NOSTART),
|
2018-02-05 16:41:15 +08:00
|
|
|
[TRANS_STATE_COMPLETED] = (__TRANS_START |
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
__TRANS_ATTACH |
|
|
|
|
__TRANS_JOIN |
|
Btrfs: fix deadlock between fiemap and transaction commits
The fiemap handler locks a file range that can have unflushed delalloc,
and after locking the range, it tries to attach to a running transaction.
If the running transaction started its commit, that is, it is in state
TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
flushoncommit option or the transaction is creating a snapshot for the
subvolume that contains the file that fiemap is operating on, we end up
deadlocking. This happens because fiemap is blocked on the transaction,
waiting for it to complete, and the transaction is waiting for the flushed
dealloc to complete, which requires locking the file range that the fiemap
task already locked. The following stack traces serve as an example of
when this deadlock happens:
(...)
[404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[404571.515956] Call Trace:
[404571.516360] ? __schedule+0x3ae/0x7b0
[404571.516730] schedule+0x3a/0xb0
[404571.517104] lock_extent_bits+0x1ec/0x2a0 [btrfs]
[404571.517465] ? remove_wait_queue+0x60/0x60
[404571.517832] btrfs_finish_ordered_io+0x292/0x800 [btrfs]
[404571.518202] normal_work_helper+0xea/0x530 [btrfs]
[404571.518566] process_one_work+0x21e/0x5c0
[404571.518990] worker_thread+0x4f/0x3b0
[404571.519413] ? process_one_work+0x5c0/0x5c0
[404571.519829] kthread+0x103/0x140
[404571.520191] ? kthread_create_worker_on_cpu+0x70/0x70
[404571.520565] ret_from_fork+0x3a/0x50
[404571.520915] kworker/u8:6 D 0 31651 2 0x80004000
[404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
(...)
[404571.537000] fsstress D 0 13117 13115 0x00004000
[404571.537263] Call Trace:
[404571.537524] ? __schedule+0x3ae/0x7b0
[404571.537788] schedule+0x3a/0xb0
[404571.538066] wait_current_trans+0xc8/0x100 [btrfs]
[404571.538349] ? remove_wait_queue+0x60/0x60
[404571.538680] start_transaction+0x33c/0x500 [btrfs]
[404571.539076] btrfs_check_shared+0xa3/0x1f0 [btrfs]
[404571.539513] ? extent_fiemap+0x2ce/0x650 [btrfs]
[404571.539866] extent_fiemap+0x2ce/0x650 [btrfs]
[404571.540170] do_vfs_ioctl+0x526/0x6f0
[404571.540436] ksys_ioctl+0x70/0x80
[404571.540734] __x64_sys_ioctl+0x16/0x20
[404571.540997] do_syscall_64+0x60/0x1d0
[404571.541279] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
[404571.543729] btrfs D 0 14210 14208 0x00004000
[404571.544023] Call Trace:
[404571.544275] ? __schedule+0x3ae/0x7b0
[404571.544526] ? wait_for_completion+0x112/0x1a0
[404571.544795] schedule+0x3a/0xb0
[404571.545064] schedule_timeout+0x1ff/0x390
[404571.545351] ? lock_acquire+0xa6/0x190
[404571.545638] ? wait_for_completion+0x49/0x1a0
[404571.545890] ? wait_for_completion+0x112/0x1a0
[404571.546228] wait_for_completion+0x131/0x1a0
[404571.546503] ? wake_up_q+0x70/0x70
[404571.546775] btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
[404571.547159] btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
[404571.547449] ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
[404571.547703] ? remove_wait_queue+0x60/0x60
[404571.547969] btrfs_mksubvol+0x605/0x640 [btrfs]
[404571.548226] ? __sb_start_write+0xd4/0x1c0
[404571.548512] ? mnt_want_write_file+0x24/0x50
[404571.548789] btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
[404571.549048] btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
[404571.549307] btrfs_ioctl+0x133f/0x3150 [btrfs]
[404571.549549] ? mem_cgroup_charge_statistics+0x4c/0xd0
[404571.549792] ? mem_cgroup_commit_charge+0x84/0x4b0
[404571.550064] ? __handle_mm_fault+0xe3e/0x11f0
[404571.550306] ? do_raw_spin_unlock+0x49/0xc0
[404571.550608] ? _raw_spin_unlock+0x24/0x30
[404571.550976] ? __handle_mm_fault+0xedf/0x11f0
[404571.551319] ? do_vfs_ioctl+0xa2/0x6f0
[404571.551659] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[404571.552087] do_vfs_ioctl+0xa2/0x6f0
[404571.552355] ksys_ioctl+0x70/0x80
[404571.552621] __x64_sys_ioctl+0x16/0x20
[404571.552864] do_syscall_64+0x60/0x1d0
[404571.553104] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
If we were joining the transaction instead of attaching to it, we would
not risk a deadlock because a join only blocks if the transaction is in a
state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
flush performed by a transaction is done before it reaches that state,
when it is in the state TRANS_STATE_COMMIT_START. However a transaction
join is intended for use cases where we do modify the filesystem, and
fiemap only needs to peek at delayed references from the current
transaction in order to determine if extents are shared, and, besides
that, when there is no current transaction or when it blocks to wait for
a current committing transaction to complete, it creates a new transaction
without reserving any space. Such unnecessary transactions, besides doing
unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
rotation of the precious backup roots.
So fix this by adding a new transaction join variant, named join_nostart,
which behaves like the regular join, but it does not create a transaction
when none currently exists or after waiting for a committing transaction
to complete.
Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-29 16:37:10 +08:00
|
|
|
__TRANS_JOIN_NOLOCK |
|
|
|
|
__TRANS_JOIN_NOSTART),
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
};
|
|
|
|
|
2013-09-30 23:36:38 +08:00
|
|
|
void btrfs_put_transaction(struct btrfs_transaction *transaction)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
2017-03-03 16:55:11 +08:00
|
|
|
WARN_ON(refcount_read(&transaction->use_count) == 0);
|
|
|
|
if (refcount_dec_and_test(&transaction->use_count)) {
|
2011-04-12 05:25:13 +08:00
|
|
|
BUG_ON(!list_empty(&transaction->list));
|
2018-08-23 03:51:49 +08:00
|
|
|
WARN_ON(!RB_EMPTY_ROOT(
|
|
|
|
&transaction->delayed_refs.href_root.rb_root));
|
2020-02-11 15:25:37 +08:00
|
|
|
WARN_ON(!RB_EMPTY_ROOT(
|
|
|
|
&transaction->delayed_refs.dirty_extent_root));
|
2015-02-03 23:50:16 +08:00
|
|
|
if (transaction->delayed_refs.pending_csums)
|
2016-09-20 22:05:02 +08:00
|
|
|
btrfs_err(transaction->fs_info,
|
|
|
|
"pending csums is %llu",
|
|
|
|
transaction->delayed_refs.pending_csums);
|
2015-11-28 00:12:00 +08:00
|
|
|
/*
|
|
|
|
* If any block groups are found in ->deleted_bgs then it's
|
|
|
|
* because the transaction was aborted and a commit did not
|
|
|
|
* happen (things failed before writing the new superblock
|
|
|
|
* and calling btrfs_finish_extent_commit()), so we can not
|
|
|
|
* discard the physical locations of the block groups.
|
|
|
|
*/
|
|
|
|
while (!list_empty(&transaction->deleted_bgs)) {
|
2019-10-30 02:20:18 +08:00
|
|
|
struct btrfs_block_group *cache;
|
2015-11-28 00:12:00 +08:00
|
|
|
|
|
|
|
cache = list_first_entry(&transaction->deleted_bgs,
|
2019-10-30 02:20:18 +08:00
|
|
|
struct btrfs_block_group,
|
2015-11-28 00:12:00 +08:00
|
|
|
bg_list);
|
|
|
|
list_del_init(&cache->bg_list);
|
2020-05-08 18:01:47 +08:00
|
|
|
btrfs_unfreeze_block_group(cache);
|
2015-11-28 00:12:00 +08:00
|
|
|
btrfs_put_block_group(cache);
|
|
|
|
}
|
2019-03-25 20:31:22 +08:00
|
|
|
WARN_ON(!list_empty(&transaction->dev_update_list));
|
2017-03-28 18:06:05 +08:00
|
|
|
kfree(transaction);
|
2007-03-25 23:35:08 +08:00
|
|
|
}
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
|
|
|
|
2020-01-17 22:12:45 +08:00
|
|
|
static noinline void switch_commit_roots(struct btrfs_trans_handle *trans)
|
Btrfs: async block group caching
This patch moves the caching of the block group off to a kthread in order to
allow people to allocate sooner. Instead of blocking up behind the caching
mutex, we instead kick of the caching kthread, and then attempt to make an
allocation. If we cannot, we wait on the block groups caching waitqueue, which
the caching kthread will wake the waiting threads up everytime it finds 2 meg
worth of space, and then again when its finished caching. This is how I tested
the speedup from this
mkfs the disk
mount the disk
fill the disk up with fs_mark
unmount the disk
mount the disk
time touch /mnt/foo
Without my changes this took 11 seconds on my box, with these changes it now
takes 1 second.
Another change thats been put in place is we lock the super mirror's in the
pinned extent map in order to keep us from adding that stuff as free space when
caching the block group. This doesn't really change anything else as far as the
pinned extent map is concerned, since for actual pinned extents we use
EXTENT_DIRTY, but it does mean that when we unmount we have to go in and unlock
those extents to keep from leaking memory.
I've also added a check where when we are reading block groups from disk, if the
amount of space used == the size of the block group, we go ahead and mark the
block group as cached. This drastically reduces the amount of time it takes to
cache the block groups. Using the same test as above, except doing a dd to a
file and then unmounting, it used to take 33 seconds to umount, now it takes 3
seconds.
This version uses the commit_root in the caching kthread, and then keeps track
of how many async caching threads are running at any given time so if one of the
async threads is still running as we cross transactions we can wait until its
finished before handling the pinned extents. Thank you,
Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-07-14 09:29:25 +08:00
|
|
|
{
|
2020-01-17 22:12:45 +08:00
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
2018-02-07 23:55:47 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2014-03-14 03:42:13 +08:00
|
|
|
struct btrfs_root *root, *tmp;
|
|
|
|
|
|
|
|
down_write(&fs_info->commit_root_sem);
|
2020-01-17 22:12:45 +08:00
|
|
|
list_for_each_entry_safe(root, tmp, &cur_trans->switch_commits,
|
2014-03-14 03:42:13 +08:00
|
|
|
dirty_list) {
|
|
|
|
list_del_init(&root->dirty_list);
|
|
|
|
free_extent_buffer(root->commit_root);
|
|
|
|
root->commit_root = btrfs_root_node(root);
|
2018-08-06 13:25:24 +08:00
|
|
|
if (is_fstree(root->root_key.objectid))
|
2014-03-14 03:42:13 +08:00
|
|
|
btrfs_unpin_free_ino(root);
|
2019-03-25 20:31:24 +08:00
|
|
|
extent_io_tree_release(&root->dirty_log_pages);
|
btrfs: qgroup: Introduce per-root swapped blocks infrastructure
To allow delayed subtree swap rescan, btrfs needs to record per-root
information about which tree blocks get swapped. This patch introduces
the required infrastructure.
The designed workflow will be:
1) Record the subtree root block that gets swapped.
During subtree swap:
O = Old tree blocks
N = New tree blocks
reloc tree subvolume tree X
Root Root
/ \ / \
NA OB OA OB
/ | | \ / | | \
NC ND OE OF OC OD OE OF
In this case, NA and OA are going to be swapped, record (NA, OA) into
subvolume tree X.
2) After subtree swap.
reloc tree subvolume tree X
Root Root
/ \ / \
OA OB NA OB
/ | | \ / | | \
OC OD OE OF NC ND OE OF
3a) COW happens for OB
If we are going to COW tree block OB, we check OB's bytenr against
tree X's swapped_blocks structure.
If it doesn't fit any, nothing will happen.
3b) COW happens for NA
Check NA's bytenr against tree X's swapped_blocks, and get a hit.
Then we do subtree scan on both subtrees OA and NA.
Resulting 6 tree blocks to be scanned (OA, OC, OD, NA, NC, ND).
Then no matter what we do to subvolume tree X, qgroup numbers will
still be correct.
Then NA's record gets removed from X's swapped_blocks.
4) Transaction commit
Any record in X's swapped_blocks gets removed, since there is no
modification to swapped subtrees, no need to trigger heavy qgroup
subtree rescan for them.
This will introduce 128 bytes overhead for each btrfs_root even qgroup
is not enabled. This is to reduce memory allocations and potential
failures.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-01-23 15:15:16 +08:00
|
|
|
btrfs_qgroup_clean_swapped_blocks(root);
|
2014-03-14 03:42:13 +08:00
|
|
|
}
|
2015-09-15 22:07:04 +08:00
|
|
|
|
|
|
|
/* We can free old roots now. */
|
2020-01-17 22:12:45 +08:00
|
|
|
spin_lock(&cur_trans->dropped_roots_lock);
|
|
|
|
while (!list_empty(&cur_trans->dropped_roots)) {
|
|
|
|
root = list_first_entry(&cur_trans->dropped_roots,
|
2015-09-15 22:07:04 +08:00
|
|
|
struct btrfs_root, root_list);
|
|
|
|
list_del_init(&root->root_list);
|
2020-01-17 22:12:45 +08:00
|
|
|
spin_unlock(&cur_trans->dropped_roots_lock);
|
|
|
|
btrfs_free_log(trans, root);
|
2015-09-15 22:07:04 +08:00
|
|
|
btrfs_drop_and_free_fs_root(fs_info, root);
|
2020-01-17 22:12:45 +08:00
|
|
|
spin_lock(&cur_trans->dropped_roots_lock);
|
2015-09-15 22:07:04 +08:00
|
|
|
}
|
2020-01-17 22:12:45 +08:00
|
|
|
spin_unlock(&cur_trans->dropped_roots_lock);
|
2014-03-14 03:42:13 +08:00
|
|
|
up_write(&fs_info->commit_root_sem);
|
Btrfs: async block group caching
This patch moves the caching of the block group off to a kthread in order to
allow people to allocate sooner. Instead of blocking up behind the caching
mutex, we instead kick of the caching kthread, and then attempt to make an
allocation. If we cannot, we wait on the block groups caching waitqueue, which
the caching kthread will wake the waiting threads up everytime it finds 2 meg
worth of space, and then again when its finished caching. This is how I tested
the speedup from this
mkfs the disk
mount the disk
fill the disk up with fs_mark
unmount the disk
mount the disk
time touch /mnt/foo
Without my changes this took 11 seconds on my box, with these changes it now
takes 1 second.
Another change thats been put in place is we lock the super mirror's in the
pinned extent map in order to keep us from adding that stuff as free space when
caching the block group. This doesn't really change anything else as far as the
pinned extent map is concerned, since for actual pinned extents we use
EXTENT_DIRTY, but it does mean that when we unmount we have to go in and unlock
those extents to keep from leaking memory.
I've also added a check where when we are reading block groups from disk, if the
amount of space used == the size of the block group, we go ahead and mark the
block group as cached. This drastically reduces the amount of time it takes to
cache the block groups. Using the same test as above, except doing a dd to a
file and then unmounting, it used to take 33 seconds to umount, now it takes 3
seconds.
This version uses the commit_root in the caching kthread, and then keeps track
of how many async caching threads are running at any given time so if one of the
async threads is still running as we cross transactions we can wait until its
finished before handling the pinned extents. Thank you,
Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-07-14 09:29:25 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 15:48:27 +08:00
|
|
|
static inline void extwriter_counter_inc(struct btrfs_transaction *trans,
|
|
|
|
unsigned int type)
|
|
|
|
{
|
|
|
|
if (type & TRANS_EXTWRITERS)
|
|
|
|
atomic_inc(&trans->num_extwriters);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void extwriter_counter_dec(struct btrfs_transaction *trans,
|
|
|
|
unsigned int type)
|
|
|
|
{
|
|
|
|
if (type & TRANS_EXTWRITERS)
|
|
|
|
atomic_dec(&trans->num_extwriters);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void extwriter_counter_init(struct btrfs_transaction *trans,
|
|
|
|
unsigned int type)
|
|
|
|
{
|
|
|
|
atomic_set(&trans->num_extwriters, ((type & TRANS_EXTWRITERS) ? 1 : 0));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int extwriter_counter_read(struct btrfs_transaction *trans)
|
|
|
|
{
|
|
|
|
return atomic_read(&trans->num_extwriters);
|
Btrfs: fix the deadlock between the transaction start/attach and commit
Now btrfs_commit_transaction() does this
ret = btrfs_run_ordered_operations(root, 0)
which async flushes all inodes on the ordered operations list, it introduced
a deadlock that transaction-start task, transaction-commit task and the flush
workers waited for each other.
(See the following URL to get the detail
http://marc.info/?l=linux-btrfs&m=136070705732646&w=2)
As we know, if ->in_commit is set, it means someone is committing the
current transaction, we should not try to join it if we are not JOIN
or JOIN_NOLOCK, wait is the best choice for it. In this way, we can avoid
the above problem. In this way, there is another benefit: there is no new
transaction handle to block the transaction which is on the way of commit,
once we set ->in_commit.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:16:24 +08:00
|
|
|
}
|
|
|
|
|
2019-06-20 03:11:59 +08:00
|
|
|
/*
|
|
|
|
* To be called after all the new block groups attached to the transaction
|
|
|
|
* handle have been created (btrfs_create_pending_block_groups()).
|
|
|
|
*/
|
|
|
|
void btrfs_trans_release_chunk_metadata(struct btrfs_trans_handle *trans)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
|
|
|
|
|
|
|
if (!trans->chunk_bytes_reserved)
|
|
|
|
return;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(!list_empty(&trans->new_bgs));
|
|
|
|
|
|
|
|
btrfs_block_rsv_release(fs_info, &fs_info->chunk_block_rsv,
|
2020-03-10 16:59:31 +08:00
|
|
|
trans->chunk_bytes_reserved, NULL);
|
2019-06-20 03:11:59 +08:00
|
|
|
trans->chunk_bytes_reserved = 0;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* either allocate a new transaction or hop into the existing one
|
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
static noinline int join_transaction(struct btrfs_fs_info *fs_info,
|
|
|
|
unsigned int type)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
|
|
|
struct btrfs_transaction *cur_trans;
|
2011-04-12 05:25:13 +08:00
|
|
|
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
2011-11-06 16:26:19 +08:00
|
|
|
loop:
|
2012-03-02 00:24:58 +08:00
|
|
|
/* The file system has been taken offline. No new transactions. */
|
2013-01-29 18:14:48 +08:00
|
|
|
if (test_bit(BTRFS_FS_STATE_ERROR, &fs_info->fs_state)) {
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2012-03-02 00:24:58 +08:00
|
|
|
return -EROFS;
|
|
|
|
}
|
|
|
|
|
2012-05-20 21:42:19 +08:00
|
|
|
cur_trans = fs_info->running_transaction;
|
2011-04-12 05:25:13 +08:00
|
|
|
if (cur_trans) {
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(cur_trans)) {
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2012-03-02 00:24:58 +08:00
|
|
|
return cur_trans->aborted;
|
2012-04-03 00:31:37 +08:00
|
|
|
}
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
if (btrfs_blocked_trans_types[cur_trans->state] & type) {
|
Btrfs: fix the deadlock between the transaction start/attach and commit
Now btrfs_commit_transaction() does this
ret = btrfs_run_ordered_operations(root, 0)
which async flushes all inodes on the ordered operations list, it introduced
a deadlock that transaction-start task, transaction-commit task and the flush
workers waited for each other.
(See the following URL to get the detail
http://marc.info/?l=linux-btrfs&m=136070705732646&w=2)
As we know, if ->in_commit is set, it means someone is committing the
current transaction, we should not try to join it if we are not JOIN
or JOIN_NOLOCK, wait is the best choice for it. In this way, we can avoid
the above problem. In this way, there is another benefit: there is no new
transaction handle to block the transaction which is on the way of commit,
once we set ->in_commit.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:16:24 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
2011-04-12 03:45:29 +08:00
|
|
|
atomic_inc(&cur_trans->num_writers);
|
2013-05-15 15:48:27 +08:00
|
|
|
extwriter_counter_inc(cur_trans, type);
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2011-04-12 05:25:13 +08:00
|
|
|
return 0;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2011-04-12 05:25:13 +08:00
|
|
|
|
Btrfs: fix orphan transaction on the freezed filesystem
With the following debug patch:
static int btrfs_freeze(struct super_block *sb)
{
+ struct btrfs_fs_info *fs_info = btrfs_sb(sb);
+ struct btrfs_transaction *trans;
+
+ spin_lock(&fs_info->trans_lock);
+ trans = fs_info->running_transaction;
+ if (trans) {
+ printk("Transid %llu, use_count %d, num_writer %d\n",
+ trans->transid, atomic_read(&trans->use_count),
+ atomic_read(&trans->num_writers));
+ }
+ spin_unlock(&fs_info->trans_lock);
return 0;
}
I found there was a orphan transaction after the freeze operation was done.
It is because the transaction may not be committed when the transaction handle
end even though it is the last handle of the current transaction. This design
avoid committing the transaction frequently, but also introduce the above
problem.
So I add btrfs_attach_transaction() which can catch the current transaction
and commit it. If there is no transaction, it will return ENOENT, and do not
anything.
This function also can be used to instead of btrfs_join_transaction_freeze()
because it don't increase the writer counter and don't start a new transaction,
so it also can fix the deadlock between sync and freeze.
Besides that, it is used to instead of btrfs_join_transaction() in
transaction_kthread(), because if there is no transaction, the transaction
kthread needn't anything.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
2012-09-20 15:54:00 +08:00
|
|
|
/*
|
|
|
|
* If we are ATTACH, we just want to catch the current transaction,
|
|
|
|
* and commit it. If there is no transaction, just return ENOENT.
|
|
|
|
*/
|
|
|
|
if (type == TRANS_ATTACH)
|
|
|
|
return -ENOENT;
|
|
|
|
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
/*
|
|
|
|
* JOIN_NOLOCK only happens during the transaction commit, so
|
|
|
|
* it is impossible that ->running_transaction is NULL
|
|
|
|
*/
|
|
|
|
BUG_ON(type == TRANS_JOIN_NOLOCK);
|
|
|
|
|
2017-03-28 18:06:05 +08:00
|
|
|
cur_trans = kmalloc(sizeof(*cur_trans), GFP_NOFS);
|
2011-04-12 05:25:13 +08:00
|
|
|
if (!cur_trans)
|
|
|
|
return -ENOMEM;
|
2011-11-06 16:26:19 +08:00
|
|
|
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
if (fs_info->running_transaction) {
|
2011-11-06 16:26:19 +08:00
|
|
|
/*
|
|
|
|
* someone started a transaction after we unlocked. Make sure
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
* to redo the checks above
|
2011-11-06 16:26:19 +08:00
|
|
|
*/
|
2017-03-28 18:06:05 +08:00
|
|
|
kfree(cur_trans);
|
2011-11-06 16:26:19 +08:00
|
|
|
goto loop;
|
2013-01-29 18:14:48 +08:00
|
|
|
} else if (test_bit(BTRFS_FS_STATE_ERROR, &fs_info->fs_state)) {
|
2012-06-19 18:30:11 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2017-03-28 18:06:05 +08:00
|
|
|
kfree(cur_trans);
|
2012-06-01 03:52:43 +08:00
|
|
|
return -EROFS;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
2011-11-06 16:26:19 +08:00
|
|
|
|
2016-09-20 22:05:02 +08:00
|
|
|
cur_trans->fs_info = fs_info;
|
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 19:43:58 +08:00
|
|
|
atomic_set(&cur_trans->pending_ordered, 0);
|
|
|
|
init_waitqueue_head(&cur_trans->pending_wait);
|
2011-04-12 05:25:13 +08:00
|
|
|
atomic_set(&cur_trans->num_writers, 1);
|
2013-05-15 15:48:27 +08:00
|
|
|
extwriter_counter_init(cur_trans, type);
|
2011-04-12 05:25:13 +08:00
|
|
|
init_waitqueue_head(&cur_trans->writer_wait);
|
|
|
|
init_waitqueue_head(&cur_trans->commit_wait);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->state = TRANS_STATE_RUNNING;
|
2011-04-12 05:25:13 +08:00
|
|
|
/*
|
|
|
|
* One for this trans handle, one so it will live on until we
|
|
|
|
* commit the transaction.
|
|
|
|
*/
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_set(&cur_trans->use_count, 2);
|
2015-09-24 22:46:10 +08:00
|
|
|
cur_trans->flags = 0;
|
2018-06-22 00:04:05 +08:00
|
|
|
cur_trans->start_time = ktime_get_seconds();
|
2011-04-12 05:25:13 +08:00
|
|
|
|
2015-09-07 22:24:37 +08:00
|
|
|
memset(&cur_trans->delayed_refs, 0, sizeof(cur_trans->delayed_refs));
|
|
|
|
|
2018-08-23 03:51:49 +08:00
|
|
|
cur_trans->delayed_refs.href_root = RB_ROOT_CACHED;
|
2015-04-16 14:34:17 +08:00
|
|
|
cur_trans->delayed_refs.dirty_extent_root = RB_ROOT;
|
2014-01-23 22:21:38 +08:00
|
|
|
atomic_set(&cur_trans->delayed_refs.num_entries, 0);
|
2012-05-20 21:43:53 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* although the tree mod log is per file system and not per transaction,
|
|
|
|
* the log must never go across transaction boundaries.
|
|
|
|
*/
|
|
|
|
smp_mb();
|
2012-11-03 18:58:34 +08:00
|
|
|
if (!list_empty(&fs_info->tree_mod_seq_list))
|
2016-09-20 22:05:00 +08:00
|
|
|
WARN(1, KERN_ERR "BTRFS: tree_mod_seq_list not empty when creating a fresh transaction\n");
|
2012-11-03 18:58:34 +08:00
|
|
|
if (!RB_EMPTY_ROOT(&fs_info->tree_mod_log))
|
2016-09-20 22:05:00 +08:00
|
|
|
WARN(1, KERN_ERR "BTRFS: tree_mod_log rb tree not empty when creating a fresh transaction\n");
|
2013-04-25 00:57:33 +08:00
|
|
|
atomic64_set(&fs_info->tree_mod_seq, 0);
|
2012-05-20 21:43:53 +08:00
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock_init(&cur_trans->delayed_refs.lock);
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&cur_trans->pending_snapshots);
|
2019-03-25 20:31:22 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->dev_update_list);
|
2014-03-14 03:42:13 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->switch_commits);
|
2014-11-18 04:45:48 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->dirty_bgs);
|
2015-04-07 03:46:08 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->io_bgs);
|
2015-09-15 22:07:04 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->dropped_roots);
|
2015-04-07 03:46:08 +08:00
|
|
|
mutex_init(&cur_trans->cache_write_mutex);
|
2014-11-18 04:45:48 +08:00
|
|
|
spin_lock_init(&cur_trans->dirty_bgs_lock);
|
2015-06-15 21:41:19 +08:00
|
|
|
INIT_LIST_HEAD(&cur_trans->deleted_bgs);
|
2015-09-15 22:07:04 +08:00
|
|
|
spin_lock_init(&cur_trans->dropped_roots_lock);
|
2012-05-20 21:42:19 +08:00
|
|
|
list_add_tail(&cur_trans->list, &fs_info->trans_list);
|
2019-03-01 10:47:58 +08:00
|
|
|
extent_io_tree_init(fs_info, &cur_trans->dirty_pages,
|
2019-03-01 10:47:59 +08:00
|
|
|
IO_TREE_TRANS_DIRTY_PAGES, fs_info->btree_inode);
|
2020-01-20 22:09:18 +08:00
|
|
|
extent_io_tree_init(fs_info, &cur_trans->pinned_extents,
|
|
|
|
IO_TREE_FS_PINNED_EXTENTS, NULL);
|
2012-05-20 21:42:19 +08:00
|
|
|
fs_info->generation++;
|
|
|
|
cur_trans->transid = fs_info->generation;
|
|
|
|
fs_info->running_transaction = cur_trans;
|
2012-03-02 00:24:58 +08:00
|
|
|
cur_trans->aborted = 0;
|
2012-05-20 21:42:19 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2007-03-23 03:59:16 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
2020-05-15 14:01:40 +08:00
|
|
|
* This does all the record keeping required to make sure that a shareable root
|
|
|
|
* is properly recorded in a given transaction. This is required to make sure
|
|
|
|
* the old root from before we joined the transaction is deleted when the
|
|
|
|
* transaction commits.
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2011-06-14 08:00:16 +08:00
|
|
|
static int record_root_in_trans(struct btrfs_trans_handle *trans,
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
struct btrfs_root *root,
|
|
|
|
int force)
|
2007-08-08 04:15:09 +08:00
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
|
2020-05-15 14:01:40 +08:00
|
|
|
if ((test_bit(BTRFS_ROOT_SHAREABLE, &root->state) &&
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
root->last_trans < trans->transid) || force) {
|
2016-06-23 06:54:23 +08:00
|
|
|
WARN_ON(root == fs_info->extent_root);
|
2017-12-19 15:44:54 +08:00
|
|
|
WARN_ON(!force && root->commit_root != root->node);
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2011-06-14 08:00:16 +08:00
|
|
|
/*
|
2014-04-02 19:51:05 +08:00
|
|
|
* see below for IN_TRANS_SETUP usage rules
|
2011-06-14 08:00:16 +08:00
|
|
|
* we have the reloc mutex held now, so there
|
|
|
|
* is only one writer in this function
|
|
|
|
*/
|
2014-04-02 19:51:05 +08:00
|
|
|
set_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state);
|
2011-06-14 08:00:16 +08:00
|
|
|
|
2014-04-02 19:51:05 +08:00
|
|
|
/* make sure readers find IN_TRANS_SETUP before
|
2011-06-14 08:00:16 +08:00
|
|
|
* they find our root->last_trans update
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->fs_roots_radix_lock);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
if (root->last_trans == trans->transid && !force) {
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->fs_roots_radix_lock);
|
2011-04-12 05:25:13 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2016-06-23 06:54:23 +08:00
|
|
|
radix_tree_tag_set(&fs_info->fs_roots_radix,
|
|
|
|
(unsigned long)root->root_key.objectid,
|
|
|
|
BTRFS_ROOT_TRANS_TAG);
|
|
|
|
spin_unlock(&fs_info->fs_roots_radix_lock);
|
2011-06-14 08:00:16 +08:00
|
|
|
root->last_trans = trans->transid;
|
|
|
|
|
|
|
|
/* this is pretty tricky. We don't want to
|
|
|
|
* take the relocation lock in btrfs_record_root_in_trans
|
|
|
|
* unless we're really doing the first setup for this root in
|
|
|
|
* this transaction.
|
|
|
|
*
|
|
|
|
* Normally we'd use root->last_trans as a flag to decide
|
|
|
|
* if we want to take the expensive mutex.
|
|
|
|
*
|
|
|
|
* But, we have to set root->last_trans before we
|
|
|
|
* init the relocation root, otherwise, we trip over warnings
|
|
|
|
* in ctree.c. The solution used here is to flag ourselves
|
2014-04-02 19:51:05 +08:00
|
|
|
* with root IN_TRANS_SETUP. When this is 1, we're still
|
2011-06-14 08:00:16 +08:00
|
|
|
* fixing up the reloc trees and everyone must wait.
|
|
|
|
*
|
|
|
|
* When this is zero, they can trust root->last_trans and fly
|
|
|
|
* through btrfs_record_root_in_trans without having to take the
|
|
|
|
* lock. smp_wmb() makes sure that all the writes above are
|
|
|
|
* done before we pop in the zero below
|
|
|
|
*/
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
btrfs_init_reloc_root(trans, root);
|
2014-06-11 04:06:56 +08:00
|
|
|
smp_mb__before_atomic();
|
2014-04-02 19:51:05 +08:00
|
|
|
clear_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state);
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2008-07-31 04:29:20 +08:00
|
|
|
|
2011-06-14 08:00:16 +08:00
|
|
|
|
2015-09-15 22:07:04 +08:00
|
|
|
void btrfs_add_dropped_root(struct btrfs_trans_handle *trans,
|
|
|
|
struct btrfs_root *root)
|
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
2015-09-15 22:07:04 +08:00
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
|
|
|
|
|
|
|
/* Add ourselves to the transaction dropped list */
|
|
|
|
spin_lock(&cur_trans->dropped_roots_lock);
|
|
|
|
list_add_tail(&root->root_list, &cur_trans->dropped_roots);
|
|
|
|
spin_unlock(&cur_trans->dropped_roots_lock);
|
|
|
|
|
|
|
|
/* Make sure we don't try to update the root at commit time */
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->fs_roots_radix_lock);
|
|
|
|
radix_tree_tag_clear(&fs_info->fs_roots_radix,
|
2015-09-15 22:07:04 +08:00
|
|
|
(unsigned long)root->root_key.objectid,
|
|
|
|
BTRFS_ROOT_TRANS_TAG);
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->fs_roots_radix_lock);
|
2015-09-15 22:07:04 +08:00
|
|
|
}
|
|
|
|
|
2011-06-14 08:00:16 +08:00
|
|
|
int btrfs_record_root_in_trans(struct btrfs_trans_handle *trans,
|
|
|
|
struct btrfs_root *root)
|
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
|
2020-05-15 14:01:40 +08:00
|
|
|
if (!test_bit(BTRFS_ROOT_SHAREABLE, &root->state))
|
2011-06-14 08:00:16 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
2014-04-02 19:51:05 +08:00
|
|
|
* see record_root_in_trans for comments about IN_TRANS_SETUP usage
|
2011-06-14 08:00:16 +08:00
|
|
|
* and barriers
|
|
|
|
*/
|
|
|
|
smp_rmb();
|
|
|
|
if (root->last_trans == trans->transid &&
|
2014-04-02 19:51:05 +08:00
|
|
|
!test_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state))
|
2011-06-14 08:00:16 +08:00
|
|
|
return 0;
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_lock(&fs_info->reloc_mutex);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
record_root_in_trans(trans, root, 0);
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_unlock(&fs_info->reloc_mutex);
|
2011-06-14 08:00:16 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
static inline int is_transaction_blocked(struct btrfs_transaction *trans)
|
|
|
|
{
|
2019-08-22 15:25:00 +08:00
|
|
|
return (trans->state >= TRANS_STATE_COMMIT_START &&
|
2013-06-11 04:47:23 +08:00
|
|
|
trans->state < TRANS_STATE_UNBLOCKED &&
|
2020-02-06 00:34:34 +08:00
|
|
|
!TRANS_ABORTED(trans));
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/* wait for commit against the current transaction to become unblocked
|
|
|
|
* when this is done, it is safe to start a new transaction, but the current
|
|
|
|
* transaction might not be fully on disk.
|
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
static void wait_current_trans(struct btrfs_fs_info *fs_info)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
2008-07-18 00:54:14 +08:00
|
|
|
struct btrfs_transaction *cur_trans;
|
2007-03-23 03:59:16 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
cur_trans = fs_info->running_transaction;
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
if (cur_trans && is_transaction_blocked(cur_trans)) {
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2011-07-14 11:17:00 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
wait_event(fs_info->transaction_wait,
|
2013-06-11 04:47:23 +08:00
|
|
|
cur_trans->state >= TRANS_STATE_UNBLOCKED ||
|
2020-02-06 00:34:34 +08:00
|
|
|
TRANS_ABORTED(cur_trans));
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
2011-04-12 05:25:13 +08:00
|
|
|
} else {
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2008-07-18 00:54:14 +08:00
|
|
|
}
|
2008-07-31 22:48:37 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
static int may_wait_transaction(struct btrfs_fs_info *fs_info, int type)
|
2010-05-16 22:48:46 +08:00
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
if (test_bit(BTRFS_FS_LOG_RECOVERING, &fs_info->flags))
|
2011-04-12 05:25:13 +08:00
|
|
|
return 0;
|
|
|
|
|
2018-02-05 16:41:16 +08:00
|
|
|
if (type == TRANS_START)
|
2010-05-16 22:48:46 +08:00
|
|
|
return 1;
|
2011-04-12 05:25:13 +08:00
|
|
|
|
2010-05-16 22:48:46 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-09-25 21:47:45 +08:00
|
|
|
static inline bool need_reserve_reloc_root(struct btrfs_root *root)
|
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
|
|
|
|
if (!fs_info->reloc_ctl ||
|
2020-05-15 14:01:40 +08:00
|
|
|
!test_bit(BTRFS_ROOT_SHAREABLE, &root->state) ||
|
2013-09-25 21:47:45 +08:00
|
|
|
root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID ||
|
|
|
|
root->reloc_root)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Btrfs: improve the noflush reservation
In some places(such as: evicting inode), we just can not flush the reserved
space of delalloc, flushing the delayed directory index and delayed inode
is OK, but we don't try to flush those things and just go back when there is
no enough space to be reserved. This patch fixes this problem.
We defined 3 types of the flush operations: NO_FLUSH, FLUSH_LIMIT and FLUSH_ALL.
If we can in the transaction, we should not flush anything, or the deadlock
would happen, so use NO_FLUSH. If we flushing the reserved space of delalloc
would cause deadlock, use FLUSH_LIMIT. In the other cases, FLUSH_ALL is used,
and we will flush all things.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2012-10-16 19:33:38 +08:00
|
|
|
static struct btrfs_trans_handle *
|
2015-09-23 04:59:15 +08:00
|
|
|
start_transaction(struct btrfs_root *root, unsigned int num_items,
|
2017-01-25 22:50:33 +08:00
|
|
|
unsigned int type, enum btrfs_reserve_flush_enum flush,
|
|
|
|
bool enforce_qgroups)
|
2008-07-31 22:48:37 +08:00
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
struct btrfs_block_rsv *delayed_refs_rsv = &fs_info->delayed_refs_rsv;
|
2010-05-16 22:48:46 +08:00
|
|
|
struct btrfs_trans_handle *h;
|
|
|
|
struct btrfs_transaction *cur_trans;
|
2011-06-08 03:07:51 +08:00
|
|
|
u64 num_bytes = 0;
|
2011-09-14 21:44:05 +08:00
|
|
|
u64 qgroup_reserved = 0;
|
2013-09-25 21:47:45 +08:00
|
|
|
bool reloc_reserved = false;
|
2020-03-14 03:28:48 +08:00
|
|
|
bool do_chunk_alloc = false;
|
2013-09-25 21:47:45 +08:00
|
|
|
int ret;
|
2011-01-06 19:30:25 +08:00
|
|
|
|
2014-06-25 00:48:28 +08:00
|
|
|
/* Send isn't supposed to start transactions. */
|
2014-07-31 06:43:18 +08:00
|
|
|
ASSERT(current->journal_info != BTRFS_SEND_TRANS_STUB);
|
2014-06-25 00:48:28 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
if (test_bit(BTRFS_FS_STATE_ERROR, &fs_info->fs_state))
|
2011-01-06 19:30:25 +08:00
|
|
|
return ERR_PTR(-EROFS);
|
2011-04-14 03:15:59 +08:00
|
|
|
|
2014-06-25 00:48:28 +08:00
|
|
|
if (current->journal_info) {
|
2013-05-15 15:48:27 +08:00
|
|
|
WARN_ON(type & TRANS_EXTWRITERS);
|
2011-04-14 03:15:59 +08:00
|
|
|
h = current->journal_info;
|
2017-11-08 08:39:58 +08:00
|
|
|
refcount_inc(&h->use_count);
|
|
|
|
WARN_ON(refcount_read(&h->use_count) > 2);
|
2011-04-14 03:15:59 +08:00
|
|
|
h->orig_rsv = h->block_rsv;
|
|
|
|
h->block_rsv = NULL;
|
|
|
|
goto got_it;
|
|
|
|
}
|
2011-06-08 03:07:51 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Do the reservation before we join the transaction so we can do all
|
|
|
|
* the appropriate flushing if need be.
|
|
|
|
*/
|
2017-01-25 22:50:33 +08:00
|
|
|
if (num_items && root != fs_info->chunk_root) {
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
struct btrfs_block_rsv *rsv = &fs_info->trans_block_rsv;
|
|
|
|
u64 delayed_refs_bytes = 0;
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
qgroup_reserved = num_items * fs_info->nodesize;
|
btrfs: qgroup: Split meta rsv type into meta_prealloc and meta_pertrans
Btrfs uses 2 different methods to reseve metadata qgroup space.
1) Reserve at btrfs_start_transaction() time
This is quite straightforward, caller will use the trans handler
allocated to modify b-trees.
In this case, reserved metadata should be kept until qgroup numbers
are updated.
2) Reserve by using block_rsv first, and later btrfs_join_transaction()
This is more complicated, caller will reserve space using block_rsv
first, and then later call btrfs_join_transaction() to get a trans
handle.
In this case, before we modify trees, the reserved space can be
modified on demand, and after btrfs_join_transaction(), such reserved
space should also be kept until qgroup numbers are updated.
Since these two types behave differently, split the original "META"
reservation type into 2 sub-types:
META_PERTRANS:
For above case 1)
META_PREALLOC:
For reservations that happened before btrfs_join_transaction() of
case 2)
NOTE: This patch will only convert existing qgroup meta reservation
callers according to its situation, not ensuring all callers are at
correct timing.
Such fix will be added in later patches.
Signed-off-by: Qu Wenruo <wqu@suse.com>
[ update comments ]
Signed-off-by: David Sterba <dsterba@suse.com>
2017-12-12 15:34:29 +08:00
|
|
|
ret = btrfs_qgroup_reserve_meta_pertrans(root, qgroup_reserved,
|
|
|
|
enforce_qgroups);
|
2015-09-08 17:22:41 +08:00
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
2011-09-14 21:44:05 +08:00
|
|
|
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
/*
|
|
|
|
* We want to reserve all the bytes we may need all at once, so
|
|
|
|
* we only do 1 enospc flushing cycle per transaction start. We
|
|
|
|
* accomplish this by simply assuming we'll do 2 x num_items
|
|
|
|
* worth of delayed refs updates in this trans handle, and
|
|
|
|
* refill that amount for whatever is missing in the reserve.
|
|
|
|
*/
|
2019-08-23 03:14:33 +08:00
|
|
|
num_bytes = btrfs_calc_insert_metadata_size(fs_info, num_items);
|
2020-03-14 03:58:05 +08:00
|
|
|
if (flush == BTRFS_RESERVE_FLUSH_ALL &&
|
|
|
|
delayed_refs_rsv->full == 0) {
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
delayed_refs_bytes = num_bytes;
|
|
|
|
num_bytes <<= 1;
|
|
|
|
}
|
|
|
|
|
2013-09-25 21:47:45 +08:00
|
|
|
/*
|
|
|
|
* Do the reservation for the relocation root creation
|
|
|
|
*/
|
2014-09-30 07:33:33 +08:00
|
|
|
if (need_reserve_reloc_root(root)) {
|
2016-06-23 06:54:23 +08:00
|
|
|
num_bytes += fs_info->nodesize;
|
2013-09-25 21:47:45 +08:00
|
|
|
reloc_reserved = true;
|
|
|
|
}
|
|
|
|
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
ret = btrfs_block_rsv_add(root, rsv, num_bytes, flush);
|
|
|
|
if (ret)
|
|
|
|
goto reserve_fail;
|
|
|
|
if (delayed_refs_bytes) {
|
|
|
|
btrfs_migrate_to_delayed_refs_rsv(fs_info, rsv,
|
|
|
|
delayed_refs_bytes);
|
|
|
|
num_bytes -= delayed_refs_bytes;
|
|
|
|
}
|
2020-03-14 03:28:48 +08:00
|
|
|
|
|
|
|
if (rsv->space_info->force_alloc)
|
|
|
|
do_chunk_alloc = true;
|
btrfs: introduce delayed_refs_rsv
Traditionally we've had voodoo in btrfs to account for the space that
delayed refs may take up by having a global_block_rsv. This works most
of the time, except when it doesn't. We've had issues reported and seen
in production where sometimes the global reserve is exhausted during
transaction commit before we can run all of our delayed refs, resulting
in an aborted transaction. Because of this voodoo we have equally
dubious flushing semantics around throttling delayed refs which we often
get wrong.
So instead give them their own block_rsv. This way we can always know
exactly how much outstanding space we need for delayed refs. This
allows us to make sure we are constantly filling that reservation up
with space, and allows us to put more precise pressure on the enospc
system. Instead of doing math to see if its a good time to throttle,
the normal enospc code will be invoked if we have a lot of delayed refs
pending, and they will be run via the normal flushing mechanism.
For now the delayed_refs_rsv will hold the reservations for the delayed
refs, the block group updates, and deleting csums. We could have a
separate rsv for the block group updates, but the csum deletion stuff is
still handled via the delayed_refs so that will stay there.
Historical background:
The global reserve has grown to cover everything we don't reserve space
explicitly for, and we've grown a lot of weird ad-hoc heuristics to know
if we're running short on space and when it's time to force a commit. A
failure rate of 20-40 file systems when we run hundreds of thousands of
them isn't super high, but cleaning up this code will make things less
ugly and more predictible.
Thus the delayed refs rsv. We always know how many delayed refs we have
outstanding, and although running them generates more we can use the
global reserve for that spill over, which fits better into it's desired
use than a full blown reservation. This first approach is to simply
take how many times we're reserving space for and multiply that by 2 in
order to save enough space for the delayed refs that could be generated.
This is a niave approach and will probably evolve, but for now it works.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com> # high-level review
[ added background notes from the cover letter ]
Signed-off-by: David Sterba <dsterba@suse.com>
2018-12-03 23:20:33 +08:00
|
|
|
} else if (num_items == 0 && flush == BTRFS_RESERVE_FLUSH_ALL &&
|
|
|
|
!delayed_refs_rsv->full) {
|
|
|
|
/*
|
|
|
|
* Some people call with btrfs_start_transaction(root, 0)
|
|
|
|
* because they can be throttled, but have some other mechanism
|
|
|
|
* for reserving space. We still want these guys to refill the
|
|
|
|
* delayed block_rsv so just add 1 items worth of reservation
|
|
|
|
* here.
|
|
|
|
*/
|
|
|
|
ret = btrfs_delayed_refs_rsv_refill(fs_info, flush);
|
2011-06-08 03:07:51 +08:00
|
|
|
if (ret)
|
2013-01-28 20:36:22 +08:00
|
|
|
goto reserve_fail;
|
2011-06-08 03:07:51 +08:00
|
|
|
}
|
2010-05-16 22:48:46 +08:00
|
|
|
again:
|
2015-08-28 07:53:45 +08:00
|
|
|
h = kmem_cache_zalloc(btrfs_trans_handle_cachep, GFP_NOFS);
|
2013-01-28 20:36:22 +08:00
|
|
|
if (!h) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto alloc_fail;
|
|
|
|
}
|
2008-07-31 22:48:37 +08:00
|
|
|
|
2012-09-14 23:22:38 +08:00
|
|
|
/*
|
|
|
|
* If we are JOIN_NOLOCK we're already committing a transaction and
|
|
|
|
* waiting on this guy, so we don't need to do the sb_start_intwrite
|
|
|
|
* because we're already holding a ref. We need this because we could
|
|
|
|
* have raced in and did an fsync() on a file which can kick a commit
|
|
|
|
* and then we deadlock with somebody doing a freeze.
|
Btrfs: fix orphan transaction on the freezed filesystem
With the following debug patch:
static int btrfs_freeze(struct super_block *sb)
{
+ struct btrfs_fs_info *fs_info = btrfs_sb(sb);
+ struct btrfs_transaction *trans;
+
+ spin_lock(&fs_info->trans_lock);
+ trans = fs_info->running_transaction;
+ if (trans) {
+ printk("Transid %llu, use_count %d, num_writer %d\n",
+ trans->transid, atomic_read(&trans->use_count),
+ atomic_read(&trans->num_writers));
+ }
+ spin_unlock(&fs_info->trans_lock);
return 0;
}
I found there was a orphan transaction after the freeze operation was done.
It is because the transaction may not be committed when the transaction handle
end even though it is the last handle of the current transaction. This design
avoid committing the transaction frequently, but also introduce the above
problem.
So I add btrfs_attach_transaction() which can catch the current transaction
and commit it. If there is no transaction, it will return ENOENT, and do not
anything.
This function also can be used to instead of btrfs_join_transaction_freeze()
because it don't increase the writer counter and don't start a new transaction,
so it also can fix the deadlock between sync and freeze.
Besides that, it is used to instead of btrfs_join_transaction() in
transaction_kthread(), because if there is no transaction, the transaction
kthread needn't anything.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
2012-09-20 15:54:00 +08:00
|
|
|
*
|
|
|
|
* If we are ATTACH, it means we just want to catch the current
|
|
|
|
* transaction and commit it, so we needn't do sb_start_intwrite().
|
2012-09-14 23:22:38 +08:00
|
|
|
*/
|
2013-05-15 15:48:27 +08:00
|
|
|
if (type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
sb_start_intwrite(fs_info->sb);
|
2012-06-12 22:20:45 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
if (may_wait_transaction(fs_info, type))
|
|
|
|
wait_current_trans(fs_info);
|
2010-05-16 22:48:46 +08:00
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
do {
|
2016-06-23 06:54:24 +08:00
|
|
|
ret = join_transaction(fs_info, type);
|
Btrfs: fix the deadlock between the transaction start/attach and commit
Now btrfs_commit_transaction() does this
ret = btrfs_run_ordered_operations(root, 0)
which async flushes all inodes on the ordered operations list, it introduced
a deadlock that transaction-start task, transaction-commit task and the flush
workers waited for each other.
(See the following URL to get the detail
http://marc.info/?l=linux-btrfs&m=136070705732646&w=2)
As we know, if ->in_commit is set, it means someone is committing the
current transaction, we should not try to join it if we are not JOIN
or JOIN_NOLOCK, wait is the best choice for it. In this way, we can avoid
the above problem. In this way, there is another benefit: there is no new
transaction handle to block the transaction which is on the way of commit,
once we set ->in_commit.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:16:24 +08:00
|
|
|
if (ret == -EBUSY) {
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_current_trans(fs_info);
|
Btrfs: fix deadlock between fiemap and transaction commits
The fiemap handler locks a file range that can have unflushed delalloc,
and after locking the range, it tries to attach to a running transaction.
If the running transaction started its commit, that is, it is in state
TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
flushoncommit option or the transaction is creating a snapshot for the
subvolume that contains the file that fiemap is operating on, we end up
deadlocking. This happens because fiemap is blocked on the transaction,
waiting for it to complete, and the transaction is waiting for the flushed
dealloc to complete, which requires locking the file range that the fiemap
task already locked. The following stack traces serve as an example of
when this deadlock happens:
(...)
[404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[404571.515956] Call Trace:
[404571.516360] ? __schedule+0x3ae/0x7b0
[404571.516730] schedule+0x3a/0xb0
[404571.517104] lock_extent_bits+0x1ec/0x2a0 [btrfs]
[404571.517465] ? remove_wait_queue+0x60/0x60
[404571.517832] btrfs_finish_ordered_io+0x292/0x800 [btrfs]
[404571.518202] normal_work_helper+0xea/0x530 [btrfs]
[404571.518566] process_one_work+0x21e/0x5c0
[404571.518990] worker_thread+0x4f/0x3b0
[404571.519413] ? process_one_work+0x5c0/0x5c0
[404571.519829] kthread+0x103/0x140
[404571.520191] ? kthread_create_worker_on_cpu+0x70/0x70
[404571.520565] ret_from_fork+0x3a/0x50
[404571.520915] kworker/u8:6 D 0 31651 2 0x80004000
[404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
(...)
[404571.537000] fsstress D 0 13117 13115 0x00004000
[404571.537263] Call Trace:
[404571.537524] ? __schedule+0x3ae/0x7b0
[404571.537788] schedule+0x3a/0xb0
[404571.538066] wait_current_trans+0xc8/0x100 [btrfs]
[404571.538349] ? remove_wait_queue+0x60/0x60
[404571.538680] start_transaction+0x33c/0x500 [btrfs]
[404571.539076] btrfs_check_shared+0xa3/0x1f0 [btrfs]
[404571.539513] ? extent_fiemap+0x2ce/0x650 [btrfs]
[404571.539866] extent_fiemap+0x2ce/0x650 [btrfs]
[404571.540170] do_vfs_ioctl+0x526/0x6f0
[404571.540436] ksys_ioctl+0x70/0x80
[404571.540734] __x64_sys_ioctl+0x16/0x20
[404571.540997] do_syscall_64+0x60/0x1d0
[404571.541279] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
[404571.543729] btrfs D 0 14210 14208 0x00004000
[404571.544023] Call Trace:
[404571.544275] ? __schedule+0x3ae/0x7b0
[404571.544526] ? wait_for_completion+0x112/0x1a0
[404571.544795] schedule+0x3a/0xb0
[404571.545064] schedule_timeout+0x1ff/0x390
[404571.545351] ? lock_acquire+0xa6/0x190
[404571.545638] ? wait_for_completion+0x49/0x1a0
[404571.545890] ? wait_for_completion+0x112/0x1a0
[404571.546228] wait_for_completion+0x131/0x1a0
[404571.546503] ? wake_up_q+0x70/0x70
[404571.546775] btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
[404571.547159] btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
[404571.547449] ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
[404571.547703] ? remove_wait_queue+0x60/0x60
[404571.547969] btrfs_mksubvol+0x605/0x640 [btrfs]
[404571.548226] ? __sb_start_write+0xd4/0x1c0
[404571.548512] ? mnt_want_write_file+0x24/0x50
[404571.548789] btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
[404571.549048] btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
[404571.549307] btrfs_ioctl+0x133f/0x3150 [btrfs]
[404571.549549] ? mem_cgroup_charge_statistics+0x4c/0xd0
[404571.549792] ? mem_cgroup_commit_charge+0x84/0x4b0
[404571.550064] ? __handle_mm_fault+0xe3e/0x11f0
[404571.550306] ? do_raw_spin_unlock+0x49/0xc0
[404571.550608] ? _raw_spin_unlock+0x24/0x30
[404571.550976] ? __handle_mm_fault+0xedf/0x11f0
[404571.551319] ? do_vfs_ioctl+0xa2/0x6f0
[404571.551659] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[404571.552087] do_vfs_ioctl+0xa2/0x6f0
[404571.552355] ksys_ioctl+0x70/0x80
[404571.552621] __x64_sys_ioctl+0x16/0x20
[404571.552864] do_syscall_64+0x60/0x1d0
[404571.553104] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
If we were joining the transaction instead of attaching to it, we would
not risk a deadlock because a join only blocks if the transaction is in a
state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
flush performed by a transaction is done before it reaches that state,
when it is in the state TRANS_STATE_COMMIT_START. However a transaction
join is intended for use cases where we do modify the filesystem, and
fiemap only needs to peek at delayed references from the current
transaction in order to determine if extents are shared, and, besides
that, when there is no current transaction or when it blocks to wait for
a current committing transaction to complete, it creates a new transaction
without reserving any space. Such unnecessary transactions, besides doing
unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
rotation of the precious backup roots.
So fix this by adding a new transaction join variant, named join_nostart,
which behaves like the regular join, but it does not create a transaction
when none currently exists or after waiting for a committing transaction
to complete.
Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-29 16:37:10 +08:00
|
|
|
if (unlikely(type == TRANS_ATTACH ||
|
|
|
|
type == TRANS_JOIN_NOSTART))
|
Btrfs: fix the deadlock between the transaction start/attach and commit
Now btrfs_commit_transaction() does this
ret = btrfs_run_ordered_operations(root, 0)
which async flushes all inodes on the ordered operations list, it introduced
a deadlock that transaction-start task, transaction-commit task and the flush
workers waited for each other.
(See the following URL to get the detail
http://marc.info/?l=linux-btrfs&m=136070705732646&w=2)
As we know, if ->in_commit is set, it means someone is committing the
current transaction, we should not try to join it if we are not JOIN
or JOIN_NOLOCK, wait is the best choice for it. In this way, we can avoid
the above problem. In this way, there is another benefit: there is no new
transaction handle to block the transaction which is on the way of commit,
once we set ->in_commit.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:16:24 +08:00
|
|
|
ret = -ENOENT;
|
|
|
|
}
|
2011-04-12 05:25:13 +08:00
|
|
|
} while (ret == -EBUSY);
|
|
|
|
|
2016-09-14 10:15:48 +08:00
|
|
|
if (ret < 0)
|
2013-01-28 20:36:22 +08:00
|
|
|
goto join_fail;
|
2007-04-09 22:42:37 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
cur_trans = fs_info->running_transaction;
|
2010-05-16 22:48:46 +08:00
|
|
|
|
|
|
|
h->transid = cur_trans->transid;
|
|
|
|
h->transaction = cur_trans;
|
2011-09-13 17:40:09 +08:00
|
|
|
h->root = root;
|
2017-11-08 08:39:58 +08:00
|
|
|
refcount_set(&h->use_count, 1);
|
2016-06-21 05:23:41 +08:00
|
|
|
h->fs_info = root->fs_info;
|
2015-09-08 17:22:41 +08:00
|
|
|
|
2012-09-20 15:51:59 +08:00
|
|
|
h->type = type;
|
2015-10-03 20:13:13 +08:00
|
|
|
h->can_flush_pending_bgs = true;
|
2012-09-12 04:57:25 +08:00
|
|
|
INIT_LIST_HEAD(&h->new_bgs);
|
2009-03-13 08:12:45 +08:00
|
|
|
|
2010-05-16 22:48:46 +08:00
|
|
|
smp_mb();
|
2019-08-22 15:25:00 +08:00
|
|
|
if (cur_trans->state >= TRANS_STATE_COMMIT_START &&
|
2016-06-23 06:54:24 +08:00
|
|
|
may_wait_transaction(fs_info, type)) {
|
2014-06-25 00:46:58 +08:00
|
|
|
current->journal_info = h;
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_commit_transaction(h);
|
2010-05-16 22:48:46 +08:00
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
|
2011-06-08 03:07:51 +08:00
|
|
|
if (num_bytes) {
|
2016-06-23 06:54:23 +08:00
|
|
|
trace_btrfs_space_reservation(fs_info, "transaction",
|
2012-03-29 21:57:44 +08:00
|
|
|
h->transid, num_bytes, 1);
|
2016-06-23 06:54:23 +08:00
|
|
|
h->block_rsv = &fs_info->trans_block_rsv;
|
2011-06-08 03:07:51 +08:00
|
|
|
h->bytes_reserved = num_bytes;
|
2013-09-25 21:47:45 +08:00
|
|
|
h->reloc_reserved = reloc_reserved;
|
2010-05-16 22:48:46 +08:00
|
|
|
}
|
2009-09-12 04:12:44 +08:00
|
|
|
|
2011-04-14 03:15:59 +08:00
|
|
|
got_it:
|
2018-02-05 16:41:15 +08:00
|
|
|
if (!current->journal_info)
|
2010-05-16 22:48:46 +08:00
|
|
|
current->journal_info = h;
|
btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
[BUG]
One run of btrfs/063 triggered the following lockdep warning:
============================================
WARNING: possible recursive locking detected
5.6.0-rc7-custom+ #48 Not tainted
--------------------------------------------
kworker/u24:0/7 is trying to acquire lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
but task is already holding lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sb_internal#2);
lock(sb_internal#2);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u24:0/7:
#0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80
#1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80
#2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
#3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]
stack backtrace:
CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
Call Trace:
dump_stack+0xc2/0x11a
__lock_acquire.cold+0xce/0x214
lock_acquire+0xe6/0x210
__sb_start_write+0x14e/0x290
start_transaction+0x66c/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
find_free_extent+0x1504/0x1a50 [btrfs]
btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
btrfs_alloc_tree_block+0x1ac/0x570 [btrfs]
btrfs_copy_root+0x213/0x580 [btrfs]
create_reloc_root+0x3bd/0x470 [btrfs]
btrfs_init_reloc_root+0x2d2/0x310 [btrfs]
record_root_in_trans+0x191/0x1d0 [btrfs]
btrfs_record_root_in_trans+0x90/0xd0 [btrfs]
start_transaction+0x16e/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs]
finish_ordered_fn+0x15/0x20 [btrfs]
btrfs_work_helper+0x116/0x9a0 [btrfs]
process_one_work+0x632/0xb80
worker_thread+0x80/0x690
kthread+0x1a3/0x1f0
ret_from_fork+0x27/0x50
It's pretty hard to reproduce, only one hit so far.
[CAUSE]
This is because we're calling btrfs_join_transaction() without re-using
the current running one:
btrfs_finish_ordered_io()
|- btrfs_join_transaction() <<< Call #1
|- btrfs_record_root_in_trans()
|- btrfs_reserve_extent()
|- btrfs_join_transaction() <<< Call #2
Normally such btrfs_join_transaction() call should re-use the existing
one, without trying to re-start a transaction.
But the problem is, in btrfs_join_transaction() call #1, we call
btrfs_record_root_in_trans() before initializing current::journal_info.
And in btrfs_join_transaction() call #2, we're relying on
current::journal_info to avoid such deadlock.
[FIX]
Call btrfs_record_root_in_trans() after we have initialized
current::journal_info.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-04-27 14:50:14 +08:00
|
|
|
|
2020-03-14 03:28:48 +08:00
|
|
|
/*
|
|
|
|
* If the space_info is marked ALLOC_FORCE then we'll get upgraded to
|
|
|
|
* ALLOC_FORCE the first run through, and then we won't allocate for
|
|
|
|
* anybody else who races in later. We don't care about the return
|
|
|
|
* value here.
|
|
|
|
*/
|
|
|
|
if (do_chunk_alloc && num_bytes) {
|
|
|
|
u64 flags = h->block_rsv->space_info->flags;
|
|
|
|
|
|
|
|
btrfs_chunk_alloc(h, btrfs_get_alloc_profile(fs_info, flags),
|
|
|
|
CHUNK_ALLOC_NO_FORCE);
|
|
|
|
}
|
|
|
|
|
btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
[BUG]
One run of btrfs/063 triggered the following lockdep warning:
============================================
WARNING: possible recursive locking detected
5.6.0-rc7-custom+ #48 Not tainted
--------------------------------------------
kworker/u24:0/7 is trying to acquire lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
but task is already holding lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sb_internal#2);
lock(sb_internal#2);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u24:0/7:
#0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80
#1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80
#2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
#3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]
stack backtrace:
CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
Call Trace:
dump_stack+0xc2/0x11a
__lock_acquire.cold+0xce/0x214
lock_acquire+0xe6/0x210
__sb_start_write+0x14e/0x290
start_transaction+0x66c/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
find_free_extent+0x1504/0x1a50 [btrfs]
btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
btrfs_alloc_tree_block+0x1ac/0x570 [btrfs]
btrfs_copy_root+0x213/0x580 [btrfs]
create_reloc_root+0x3bd/0x470 [btrfs]
btrfs_init_reloc_root+0x2d2/0x310 [btrfs]
record_root_in_trans+0x191/0x1d0 [btrfs]
btrfs_record_root_in_trans+0x90/0xd0 [btrfs]
start_transaction+0x16e/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs]
finish_ordered_fn+0x15/0x20 [btrfs]
btrfs_work_helper+0x116/0x9a0 [btrfs]
process_one_work+0x632/0xb80
worker_thread+0x80/0x690
kthread+0x1a3/0x1f0
ret_from_fork+0x27/0x50
It's pretty hard to reproduce, only one hit so far.
[CAUSE]
This is because we're calling btrfs_join_transaction() without re-using
the current running one:
btrfs_finish_ordered_io()
|- btrfs_join_transaction() <<< Call #1
|- btrfs_record_root_in_trans()
|- btrfs_reserve_extent()
|- btrfs_join_transaction() <<< Call #2
Normally such btrfs_join_transaction() call should re-use the existing
one, without trying to re-start a transaction.
But the problem is, in btrfs_join_transaction() call #1, we call
btrfs_record_root_in_trans() before initializing current::journal_info.
And in btrfs_join_transaction() call #2, we're relying on
current::journal_info to avoid such deadlock.
[FIX]
Call btrfs_record_root_in_trans() after we have initialized
current::journal_info.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2020-04-27 14:50:14 +08:00
|
|
|
/*
|
|
|
|
* btrfs_record_root_in_trans() needs to alloc new extents, and may
|
|
|
|
* call btrfs_join_transaction() while we're also starting a
|
|
|
|
* transaction.
|
|
|
|
*
|
|
|
|
* Thus it need to be called after current->journal_info initialized,
|
|
|
|
* or we can deadlock.
|
|
|
|
*/
|
|
|
|
btrfs_record_root_in_trans(h, root);
|
|
|
|
|
2007-03-23 03:59:16 +08:00
|
|
|
return h;
|
2013-01-28 20:36:22 +08:00
|
|
|
|
|
|
|
join_fail:
|
2013-05-15 15:48:27 +08:00
|
|
|
if (type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
sb_end_intwrite(fs_info->sb);
|
2013-01-28 20:36:22 +08:00
|
|
|
kmem_cache_free(btrfs_trans_handle_cachep, h);
|
|
|
|
alloc_fail:
|
|
|
|
if (num_bytes)
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_block_rsv_release(fs_info, &fs_info->trans_block_rsv,
|
2020-03-10 16:59:31 +08:00
|
|
|
num_bytes, NULL);
|
2013-01-28 20:36:22 +08:00
|
|
|
reserve_fail:
|
btrfs: qgroup: Split meta rsv type into meta_prealloc and meta_pertrans
Btrfs uses 2 different methods to reseve metadata qgroup space.
1) Reserve at btrfs_start_transaction() time
This is quite straightforward, caller will use the trans handler
allocated to modify b-trees.
In this case, reserved metadata should be kept until qgroup numbers
are updated.
2) Reserve by using block_rsv first, and later btrfs_join_transaction()
This is more complicated, caller will reserve space using block_rsv
first, and then later call btrfs_join_transaction() to get a trans
handle.
In this case, before we modify trees, the reserved space can be
modified on demand, and after btrfs_join_transaction(), such reserved
space should also be kept until qgroup numbers are updated.
Since these two types behave differently, split the original "META"
reservation type into 2 sub-types:
META_PERTRANS:
For above case 1)
META_PREALLOC:
For reservations that happened before btrfs_join_transaction() of
case 2)
NOTE: This patch will only convert existing qgroup meta reservation
callers according to its situation, not ensuring all callers are at
correct timing.
Such fix will be added in later patches.
Signed-off-by: Qu Wenruo <wqu@suse.com>
[ update comments ]
Signed-off-by: David Sterba <dsterba@suse.com>
2017-12-12 15:34:29 +08:00
|
|
|
btrfs_qgroup_free_meta_pertrans(root, qgroup_reserved);
|
2013-01-28 20:36:22 +08:00
|
|
|
return ERR_PTR(ret);
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
|
|
|
|
2008-07-18 00:54:14 +08:00
|
|
|
struct btrfs_trans_handle *btrfs_start_transaction(struct btrfs_root *root,
|
2015-09-23 04:59:15 +08:00
|
|
|
unsigned int num_items)
|
2008-07-18 00:54:14 +08:00
|
|
|
{
|
Btrfs: improve the noflush reservation
In some places(such as: evicting inode), we just can not flush the reserved
space of delalloc, flushing the delayed directory index and delayed inode
is OK, but we don't try to flush those things and just go back when there is
no enough space to be reserved. This patch fixes this problem.
We defined 3 types of the flush operations: NO_FLUSH, FLUSH_LIMIT and FLUSH_ALL.
If we can in the transaction, we should not flush anything, or the deadlock
would happen, so use NO_FLUSH. If we flushing the reserved space of delalloc
would cause deadlock, use FLUSH_LIMIT. In the other cases, FLUSH_ALL is used,
and we will flush all things.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
2012-10-16 19:33:38 +08:00
|
|
|
return start_transaction(root, num_items, TRANS_START,
|
2017-01-25 22:50:33 +08:00
|
|
|
BTRFS_RESERVE_FLUSH_ALL, true);
|
2008-07-18 00:54:14 +08:00
|
|
|
}
|
2017-01-25 22:50:33 +08:00
|
|
|
|
2015-11-14 07:57:16 +08:00
|
|
|
struct btrfs_trans_handle *btrfs_start_transaction_fallback_global_rsv(
|
|
|
|
struct btrfs_root *root,
|
2020-03-14 03:58:05 +08:00
|
|
|
unsigned int num_items)
|
2015-11-14 07:57:16 +08:00
|
|
|
{
|
2020-03-14 03:58:05 +08:00
|
|
|
return start_transaction(root, num_items, TRANS_START,
|
|
|
|
BTRFS_RESERVE_FLUSH_ALL_STEAL, false);
|
2015-11-14 07:57:16 +08:00
|
|
|
}
|
Btrfs: fix corrupted metadata in the snapshot
When we delete a inode, we will remove all the delayed items including delayed
inode update, and then truncate all the relative metadata. If there is lots of
metadata, we will end the current transaction, and start a new transaction to
truncate the left metadata. In this way, we will leave a inode item that its
link counter is > 0, and also may leave some directory index items in fs/file tree
after the current transaction ends. In other words, the metadata in this fs/file tree
is inconsistent. If we create a snapshot for this tree now, we will find a inode with
corrupted metadata in the new snapshot, and we won't continue to drop the left metadata,
because its link counter is not 0.
We fix this problem by updating the inode item before the current transaction ends.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
2012-09-07 15:43:32 +08:00
|
|
|
|
2011-04-14 00:54:33 +08:00
|
|
|
struct btrfs_trans_handle *btrfs_join_transaction(struct btrfs_root *root)
|
2008-07-18 00:54:14 +08:00
|
|
|
{
|
2017-01-25 22:50:33 +08:00
|
|
|
return start_transaction(root, 0, TRANS_JOIN, BTRFS_RESERVE_NO_FLUSH,
|
|
|
|
true);
|
2008-07-18 00:54:14 +08:00
|
|
|
}
|
|
|
|
|
2019-10-09 01:43:06 +08:00
|
|
|
struct btrfs_trans_handle *btrfs_join_transaction_spacecache(struct btrfs_root *root)
|
2010-06-22 02:48:16 +08:00
|
|
|
{
|
2015-10-26 03:35:44 +08:00
|
|
|
return start_transaction(root, 0, TRANS_JOIN_NOLOCK,
|
2017-01-25 22:50:33 +08:00
|
|
|
BTRFS_RESERVE_NO_FLUSH, true);
|
2010-06-22 02:48:16 +08:00
|
|
|
}
|
|
|
|
|
Btrfs: fix deadlock between fiemap and transaction commits
The fiemap handler locks a file range that can have unflushed delalloc,
and after locking the range, it tries to attach to a running transaction.
If the running transaction started its commit, that is, it is in state
TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
flushoncommit option or the transaction is creating a snapshot for the
subvolume that contains the file that fiemap is operating on, we end up
deadlocking. This happens because fiemap is blocked on the transaction,
waiting for it to complete, and the transaction is waiting for the flushed
dealloc to complete, which requires locking the file range that the fiemap
task already locked. The following stack traces serve as an example of
when this deadlock happens:
(...)
[404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[404571.515956] Call Trace:
[404571.516360] ? __schedule+0x3ae/0x7b0
[404571.516730] schedule+0x3a/0xb0
[404571.517104] lock_extent_bits+0x1ec/0x2a0 [btrfs]
[404571.517465] ? remove_wait_queue+0x60/0x60
[404571.517832] btrfs_finish_ordered_io+0x292/0x800 [btrfs]
[404571.518202] normal_work_helper+0xea/0x530 [btrfs]
[404571.518566] process_one_work+0x21e/0x5c0
[404571.518990] worker_thread+0x4f/0x3b0
[404571.519413] ? process_one_work+0x5c0/0x5c0
[404571.519829] kthread+0x103/0x140
[404571.520191] ? kthread_create_worker_on_cpu+0x70/0x70
[404571.520565] ret_from_fork+0x3a/0x50
[404571.520915] kworker/u8:6 D 0 31651 2 0x80004000
[404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
(...)
[404571.537000] fsstress D 0 13117 13115 0x00004000
[404571.537263] Call Trace:
[404571.537524] ? __schedule+0x3ae/0x7b0
[404571.537788] schedule+0x3a/0xb0
[404571.538066] wait_current_trans+0xc8/0x100 [btrfs]
[404571.538349] ? remove_wait_queue+0x60/0x60
[404571.538680] start_transaction+0x33c/0x500 [btrfs]
[404571.539076] btrfs_check_shared+0xa3/0x1f0 [btrfs]
[404571.539513] ? extent_fiemap+0x2ce/0x650 [btrfs]
[404571.539866] extent_fiemap+0x2ce/0x650 [btrfs]
[404571.540170] do_vfs_ioctl+0x526/0x6f0
[404571.540436] ksys_ioctl+0x70/0x80
[404571.540734] __x64_sys_ioctl+0x16/0x20
[404571.540997] do_syscall_64+0x60/0x1d0
[404571.541279] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
[404571.543729] btrfs D 0 14210 14208 0x00004000
[404571.544023] Call Trace:
[404571.544275] ? __schedule+0x3ae/0x7b0
[404571.544526] ? wait_for_completion+0x112/0x1a0
[404571.544795] schedule+0x3a/0xb0
[404571.545064] schedule_timeout+0x1ff/0x390
[404571.545351] ? lock_acquire+0xa6/0x190
[404571.545638] ? wait_for_completion+0x49/0x1a0
[404571.545890] ? wait_for_completion+0x112/0x1a0
[404571.546228] wait_for_completion+0x131/0x1a0
[404571.546503] ? wake_up_q+0x70/0x70
[404571.546775] btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
[404571.547159] btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
[404571.547449] ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
[404571.547703] ? remove_wait_queue+0x60/0x60
[404571.547969] btrfs_mksubvol+0x605/0x640 [btrfs]
[404571.548226] ? __sb_start_write+0xd4/0x1c0
[404571.548512] ? mnt_want_write_file+0x24/0x50
[404571.548789] btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
[404571.549048] btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
[404571.549307] btrfs_ioctl+0x133f/0x3150 [btrfs]
[404571.549549] ? mem_cgroup_charge_statistics+0x4c/0xd0
[404571.549792] ? mem_cgroup_commit_charge+0x84/0x4b0
[404571.550064] ? __handle_mm_fault+0xe3e/0x11f0
[404571.550306] ? do_raw_spin_unlock+0x49/0xc0
[404571.550608] ? _raw_spin_unlock+0x24/0x30
[404571.550976] ? __handle_mm_fault+0xedf/0x11f0
[404571.551319] ? do_vfs_ioctl+0xa2/0x6f0
[404571.551659] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[404571.552087] do_vfs_ioctl+0xa2/0x6f0
[404571.552355] ksys_ioctl+0x70/0x80
[404571.552621] __x64_sys_ioctl+0x16/0x20
[404571.552864] do_syscall_64+0x60/0x1d0
[404571.553104] entry_SYSCALL_64_after_hwframe+0x49/0xbe
(...)
If we were joining the transaction instead of attaching to it, we would
not risk a deadlock because a join only blocks if the transaction is in a
state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
flush performed by a transaction is done before it reaches that state,
when it is in the state TRANS_STATE_COMMIT_START. However a transaction
join is intended for use cases where we do modify the filesystem, and
fiemap only needs to peek at delayed references from the current
transaction in order to determine if extents are shared, and, besides
that, when there is no current transaction or when it blocks to wait for
a current committing transaction to complete, it creates a new transaction
without reserving any space. Such unnecessary transactions, besides doing
unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
rotation of the precious backup roots.
So fix this by adding a new transaction join variant, named join_nostart,
which behaves like the regular join, but it does not create a transaction
when none currently exists or after waiting for a committing transaction
to complete.
Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-29 16:37:10 +08:00
|
|
|
/*
|
|
|
|
* Similar to regular join but it never starts a transaction when none is
|
|
|
|
* running or after waiting for the current one to finish.
|
|
|
|
*/
|
|
|
|
struct btrfs_trans_handle *btrfs_join_transaction_nostart(struct btrfs_root *root)
|
|
|
|
{
|
|
|
|
return start_transaction(root, 0, TRANS_JOIN_NOSTART,
|
|
|
|
BTRFS_RESERVE_NO_FLUSH, true);
|
|
|
|
}
|
|
|
|
|
Btrfs: fix uncompleted transaction
In some cases, we need commit the current transaction, but don't want
to start a new one if there is no running transaction, so we introduce
the function - btrfs_attach_transaction(), which can catch the current
transaction, and return -ENOENT if there is no running transaction.
But no running transaction doesn't mean the current transction completely,
because we removed the running transaction before it completes. In some
cases, it doesn't matter. But in some special cases, such as freeze fs, we
hope the transaction is fully on disk, it will introduce some bugs, for
example, we may feeze the fs and dump the data in the disk, if the transction
doesn't complete, we would dump inconsistent data. So we need fix the above
problem for those cases.
We fixes this problem by introducing a function:
btrfs_attach_transaction_barrier()
if we hope all the transaction is fully on the disk, even they are not
running, we can use this function.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:17:06 +08:00
|
|
|
/*
|
|
|
|
* btrfs_attach_transaction() - catch the running transaction
|
|
|
|
*
|
|
|
|
* It is used when we want to commit the current the transaction, but
|
|
|
|
* don't want to start a new one.
|
|
|
|
*
|
|
|
|
* Note: If this function return -ENOENT, it just means there is no
|
|
|
|
* running transaction. But it is possible that the inactive transaction
|
|
|
|
* is still in the memory, not fully on disk. If you hope there is no
|
|
|
|
* inactive transaction in the fs when -ENOENT is returned, you should
|
|
|
|
* invoke
|
|
|
|
* btrfs_attach_transaction_barrier()
|
|
|
|
*/
|
Btrfs: fix orphan transaction on the freezed filesystem
With the following debug patch:
static int btrfs_freeze(struct super_block *sb)
{
+ struct btrfs_fs_info *fs_info = btrfs_sb(sb);
+ struct btrfs_transaction *trans;
+
+ spin_lock(&fs_info->trans_lock);
+ trans = fs_info->running_transaction;
+ if (trans) {
+ printk("Transid %llu, use_count %d, num_writer %d\n",
+ trans->transid, atomic_read(&trans->use_count),
+ atomic_read(&trans->num_writers));
+ }
+ spin_unlock(&fs_info->trans_lock);
return 0;
}
I found there was a orphan transaction after the freeze operation was done.
It is because the transaction may not be committed when the transaction handle
end even though it is the last handle of the current transaction. This design
avoid committing the transaction frequently, but also introduce the above
problem.
So I add btrfs_attach_transaction() which can catch the current transaction
and commit it. If there is no transaction, it will return ENOENT, and do not
anything.
This function also can be used to instead of btrfs_join_transaction_freeze()
because it don't increase the writer counter and don't start a new transaction,
so it also can fix the deadlock between sync and freeze.
Besides that, it is used to instead of btrfs_join_transaction() in
transaction_kthread(), because if there is no transaction, the transaction
kthread needn't anything.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
2012-09-20 15:54:00 +08:00
|
|
|
struct btrfs_trans_handle *btrfs_attach_transaction(struct btrfs_root *root)
|
2012-09-14 22:34:40 +08:00
|
|
|
{
|
2015-10-26 03:35:44 +08:00
|
|
|
return start_transaction(root, 0, TRANS_ATTACH,
|
2017-01-25 22:50:33 +08:00
|
|
|
BTRFS_RESERVE_NO_FLUSH, true);
|
2012-09-14 22:34:40 +08:00
|
|
|
}
|
|
|
|
|
Btrfs: fix uncompleted transaction
In some cases, we need commit the current transaction, but don't want
to start a new one if there is no running transaction, so we introduce
the function - btrfs_attach_transaction(), which can catch the current
transaction, and return -ENOENT if there is no running transaction.
But no running transaction doesn't mean the current transction completely,
because we removed the running transaction before it completes. In some
cases, it doesn't matter. But in some special cases, such as freeze fs, we
hope the transaction is fully on disk, it will introduce some bugs, for
example, we may feeze the fs and dump the data in the disk, if the transction
doesn't complete, we would dump inconsistent data. So we need fix the above
problem for those cases.
We fixes this problem by introducing a function:
btrfs_attach_transaction_barrier()
if we hope all the transaction is fully on the disk, even they are not
running, we can use this function.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:17:06 +08:00
|
|
|
/*
|
2013-06-14 16:21:24 +08:00
|
|
|
* btrfs_attach_transaction_barrier() - catch the running transaction
|
Btrfs: fix uncompleted transaction
In some cases, we need commit the current transaction, but don't want
to start a new one if there is no running transaction, so we introduce
the function - btrfs_attach_transaction(), which can catch the current
transaction, and return -ENOENT if there is no running transaction.
But no running transaction doesn't mean the current transction completely,
because we removed the running transaction before it completes. In some
cases, it doesn't matter. But in some special cases, such as freeze fs, we
hope the transaction is fully on disk, it will introduce some bugs, for
example, we may feeze the fs and dump the data in the disk, if the transction
doesn't complete, we would dump inconsistent data. So we need fix the above
problem for those cases.
We fixes this problem by introducing a function:
btrfs_attach_transaction_barrier()
if we hope all the transaction is fully on the disk, even they are not
running, we can use this function.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:17:06 +08:00
|
|
|
*
|
2018-11-28 19:05:13 +08:00
|
|
|
* It is similar to the above function, the difference is this one
|
Btrfs: fix uncompleted transaction
In some cases, we need commit the current transaction, but don't want
to start a new one if there is no running transaction, so we introduce
the function - btrfs_attach_transaction(), which can catch the current
transaction, and return -ENOENT if there is no running transaction.
But no running transaction doesn't mean the current transction completely,
because we removed the running transaction before it completes. In some
cases, it doesn't matter. But in some special cases, such as freeze fs, we
hope the transaction is fully on disk, it will introduce some bugs, for
example, we may feeze the fs and dump the data in the disk, if the transction
doesn't complete, we would dump inconsistent data. So we need fix the above
problem for those cases.
We fixes this problem by introducing a function:
btrfs_attach_transaction_barrier()
if we hope all the transaction is fully on the disk, even they are not
running, we can use this function.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:17:06 +08:00
|
|
|
* will wait for all the inactive transactions until they fully
|
|
|
|
* complete.
|
|
|
|
*/
|
|
|
|
struct btrfs_trans_handle *
|
|
|
|
btrfs_attach_transaction_barrier(struct btrfs_root *root)
|
|
|
|
{
|
|
|
|
struct btrfs_trans_handle *trans;
|
|
|
|
|
2015-10-26 03:35:44 +08:00
|
|
|
trans = start_transaction(root, 0, TRANS_ATTACH,
|
2017-01-25 22:50:33 +08:00
|
|
|
BTRFS_RESERVE_NO_FLUSH, true);
|
2018-07-30 06:04:46 +08:00
|
|
|
if (trans == ERR_PTR(-ENOENT))
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_wait_for_commit(root->fs_info, 0);
|
Btrfs: fix uncompleted transaction
In some cases, we need commit the current transaction, but don't want
to start a new one if there is no running transaction, so we introduce
the function - btrfs_attach_transaction(), which can catch the current
transaction, and return -ENOENT if there is no running transaction.
But no running transaction doesn't mean the current transction completely,
because we removed the running transaction before it completes. In some
cases, it doesn't matter. But in some special cases, such as freeze fs, we
hope the transaction is fully on disk, it will introduce some bugs, for
example, we may feeze the fs and dump the data in the disk, if the transction
doesn't complete, we would dump inconsistent data. So we need fix the above
problem for those cases.
We fixes this problem by introducing a function:
btrfs_attach_transaction_barrier()
if we hope all the transaction is fully on the disk, even they are not
running, we can use this function.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-02-20 17:17:06 +08:00
|
|
|
|
|
|
|
return trans;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/* wait for a transaction commit to be fully complete */
|
2016-06-23 06:54:24 +08:00
|
|
|
static noinline void wait_for_commit(struct btrfs_transaction *commit)
|
2008-06-26 04:01:31 +08:00
|
|
|
{
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
wait_event(commit->commit_wait, commit->state == TRANS_STATE_COMPLETED);
|
2008-06-26 04:01:31 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid)
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
{
|
|
|
|
struct btrfs_transaction *cur_trans = NULL, *t;
|
2012-11-26 16:42:07 +08:00
|
|
|
int ret = 0;
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
|
|
|
|
if (transid) {
|
2016-06-23 06:54:23 +08:00
|
|
|
if (transid <= fs_info->last_trans_committed)
|
2011-04-12 05:25:13 +08:00
|
|
|
goto out;
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
|
|
|
|
/* find specified transaction */
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
list_for_each_entry(t, &fs_info->trans_list, list) {
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
if (t->transid == transid) {
|
|
|
|
cur_trans = t;
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
2012-11-26 16:42:07 +08:00
|
|
|
ret = 0;
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
break;
|
|
|
|
}
|
2012-11-26 16:42:07 +08:00
|
|
|
if (t->transid > transid) {
|
|
|
|
ret = 0;
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
break;
|
2012-11-26 16:42:07 +08:00
|
|
|
}
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
}
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2014-09-26 23:30:06 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The specified transaction doesn't exist, or we
|
|
|
|
* raced with btrfs_commit_transaction
|
|
|
|
*/
|
|
|
|
if (!cur_trans) {
|
2016-06-23 06:54:23 +08:00
|
|
|
if (transid > fs_info->last_trans_committed)
|
2014-09-26 23:30:06 +08:00
|
|
|
ret = -EINVAL;
|
2012-11-26 16:42:07 +08:00
|
|
|
goto out;
|
2014-09-26 23:30:06 +08:00
|
|
|
}
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
} else {
|
|
|
|
/* find newest transaction that is committing | committed */
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
list_for_each_entry_reverse(t, &fs_info->trans_list,
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
list) {
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
if (t->state >= TRANS_STATE_COMMIT_START) {
|
|
|
|
if (t->state == TRANS_STATE_COMPLETED)
|
2011-06-09 22:15:17 +08:00
|
|
|
break;
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
cur_trans = t;
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
if (!cur_trans)
|
2011-04-12 05:25:13 +08:00
|
|
|
goto out; /* nothing committing|committed */
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_for_commit(cur_trans);
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
2011-04-12 05:25:13 +08:00
|
|
|
out:
|
Btrfs: add START_SYNC, WAIT_SYNC ioctls
START_SYNC will start a sync/commit, but not wait for it to
complete. Any modification started after the ioctl returns is
guaranteed not to be included in the commit. If a non-NULL
pointer is passed, the transaction id will be returned to
userspace.
WAIT_SYNC will wait for any in-progress commit to complete. If a
transaction id is specified, the ioctl will block and then
return (success) when the specified transaction has committed.
If it has already committed when we call the ioctl, it returns
immediately. If the specified transaction doesn't exist, it
returns EINVAL.
If no transaction id is specified, WAIT_SYNC will wait for the
currently committing transaction to finish it's commit to disk.
If there is no currently committing transaction, it returns
success.
These ioctls are useful for applications which want to impose an
ordering on when fs modifications reach disk, but do not want to
wait for the full (slow) commit process to do so.
Picky callers can take the transid returned by START_SYNC and
feed it to WAIT_SYNC, and be certain to wait only as long as
necessary for the transaction _they_ started to reach disk.
Sloppy callers can START_SYNC and WAIT_SYNC without a transid,
and provided they didn't wait too long between the calls, they
will get the same result. However, if a second commit starts
before they call WAIT_SYNC, they may end up waiting longer for
it to commit as well. Even so, a START_SYNC+WAIT_SYNC still
guarantees that any operation completed before the START_SYNC
reaches disk.
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2010-10-30 03:41:32 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
void btrfs_throttle(struct btrfs_fs_info *fs_info)
|
2008-07-31 22:48:37 +08:00
|
|
|
{
|
2018-02-05 16:41:16 +08:00
|
|
|
wait_current_trans(fs_info);
|
2008-07-31 22:48:37 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
static int should_end_transaction(struct btrfs_trans_handle *trans)
|
2010-05-16 22:49:58 +08:00
|
|
|
{
|
2016-06-23 06:54:24 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2016-06-23 06:54:23 +08:00
|
|
|
|
2018-12-03 23:20:36 +08:00
|
|
|
if (btrfs_check_space_for_delayed_refs(fs_info))
|
2013-06-13 01:56:06 +08:00
|
|
|
return 1;
|
2011-10-19 00:15:48 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
return !!btrfs_block_rsv_check(&fs_info->global_block_rsv, 5);
|
2010-05-16 22:49:58 +08:00
|
|
|
}
|
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
int btrfs_should_end_transaction(struct btrfs_trans_handle *trans)
|
2010-05-16 22:49:58 +08:00
|
|
|
{
|
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
smp_mb();
|
2019-08-22 15:25:00 +08:00
|
|
|
if (cur_trans->state >= TRANS_STATE_COMMIT_START ||
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->delayed_refs.flushing)
|
2010-05-16 22:49:58 +08:00
|
|
|
return 1;
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
return should_end_transaction(trans);
|
2010-05-16 22:49:58 +08:00
|
|
|
}
|
|
|
|
|
2018-02-07 23:55:39 +08:00
|
|
|
static void btrfs_trans_release_metadata(struct btrfs_trans_handle *trans)
|
|
|
|
|
2018-02-07 23:55:37 +08:00
|
|
|
{
|
2018-02-07 23:55:39 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
|
|
|
|
2018-02-07 23:55:37 +08:00
|
|
|
if (!trans->block_rsv) {
|
|
|
|
ASSERT(!trans->bytes_reserved);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!trans->bytes_reserved)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ASSERT(trans->block_rsv == &fs_info->trans_block_rsv);
|
|
|
|
trace_btrfs_space_reservation(fs_info, "transaction",
|
|
|
|
trans->transid, trans->bytes_reserved, 0);
|
|
|
|
btrfs_block_rsv_release(fs_info, trans->block_rsv,
|
2020-03-10 16:59:31 +08:00
|
|
|
trans->bytes_reserved, NULL);
|
2018-02-07 23:55:37 +08:00
|
|
|
trans->bytes_reserved = 0;
|
|
|
|
}
|
|
|
|
|
2008-06-26 04:01:31 +08:00
|
|
|
static int __btrfs_end_transaction(struct btrfs_trans_handle *trans,
|
2016-09-10 09:39:03 +08:00
|
|
|
int throttle)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
2016-09-10 09:39:03 +08:00
|
|
|
struct btrfs_fs_info *info = trans->fs_info;
|
2010-05-16 22:49:58 +08:00
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
2012-04-13 04:03:56 +08:00
|
|
|
int err = 0;
|
2009-03-13 22:17:05 +08:00
|
|
|
|
2017-11-08 08:39:58 +08:00
|
|
|
if (refcount_read(&trans->use_count) > 1) {
|
|
|
|
refcount_dec(&trans->use_count);
|
2011-04-14 03:15:59 +08:00
|
|
|
trans->block_rsv = trans->orig_rsv;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-07 23:55:39 +08:00
|
|
|
btrfs_trans_release_metadata(trans);
|
2011-08-30 23:31:29 +08:00
|
|
|
trans->block_rsv = NULL;
|
2011-09-14 21:44:05 +08:00
|
|
|
|
2018-11-22 03:05:42 +08:00
|
|
|
btrfs_create_pending_block_groups(trans);
|
2012-09-12 04:57:25 +08:00
|
|
|
|
Btrfs: fix -ENOSPC when finishing block group creation
While creating a block group, we often end up getting ENOSPC while updating
the chunk tree, which leads to a transaction abortion that produces a trace
like the following:
[30670.116368] WARNING: CPU: 4 PID: 20735 at fs/btrfs/super.c:260 __btrfs_abort_transaction+0x52/0x106 [btrfs]()
[30670.117777] BTRFS: Transaction aborted (error -28)
(...)
[30670.163567] Call Trace:
[30670.163906] [<ffffffff8142fa46>] dump_stack+0x4f/0x7b
[30670.164522] [<ffffffff8108b6a2>] ? console_unlock+0x361/0x3ad
[30670.165171] [<ffffffff81045ea5>] warn_slowpath_common+0xa1/0xbb
[30670.166323] [<ffffffffa035daa7>] ? __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.167213] [<ffffffff81045f05>] warn_slowpath_fmt+0x46/0x48
[30670.167862] [<ffffffffa035daa7>] __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.169116] [<ffffffffa03743d7>] btrfs_create_pending_block_groups+0x101/0x130 [btrfs]
[30670.170593] [<ffffffffa038426a>] __btrfs_end_transaction+0x84/0x366 [btrfs]
[30670.171960] [<ffffffffa038455c>] btrfs_end_transaction+0x10/0x12 [btrfs]
[30670.174649] [<ffffffffa036eb6b>] btrfs_check_data_free_space+0x11f/0x27c [btrfs]
[30670.176092] [<ffffffffa039450d>] btrfs_fallocate+0x7c8/0xb96 [btrfs]
[30670.177218] [<ffffffff812459f2>] ? __this_cpu_preempt_check+0x13/0x15
[30670.178622] [<ffffffff81152447>] vfs_fallocate+0x14c/0x1de
[30670.179642] [<ffffffff8116b915>] ? __fget_light+0x2d/0x4f
[30670.180692] [<ffffffff81152863>] SyS_fallocate+0x47/0x62
[30670.186737] [<ffffffff81435b32>] system_call_fastpath+0x12/0x17
[30670.187792] ---[ end trace 0373e6b491c4a8cc ]---
This is because we don't do proper space reservation for the chunk block
reserve when we have multiple tasks allocating chunks in parallel.
So block group creation has 2 phases, and the first phase essentially
checks if there is enough space in the system space_info, allocating a
new system chunk if there isn't, while the second phase updates the
device, extent and chunk trees. However, because the updates to the
chunk tree happen in the second phase, if we have N tasks, each with
its own transaction handle, allocating new chunks in parallel and if
there is only enough space in the system space_info to allocate M chunks,
where M < N, none of the tasks ends up allocating a new system chunk in
the first phase and N - M tasks will get -ENOSPC when attempting to
update the chunk tree in phase 2 if they need to COW any nodes/leafs
from the chunk tree.
Fix this by doing proper reservation in the chunk block reserve.
The issue could be reproduced by running fstests generic/038 in a loop,
which eventually triggered the problem.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2015-05-20 21:01:54 +08:00
|
|
|
btrfs_trans_release_chunk_metadata(trans);
|
|
|
|
|
2013-05-15 15:48:27 +08:00
|
|
|
if (trans->type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
sb_end_intwrite(info->sb);
|
2012-09-05 22:08:30 +08:00
|
|
|
|
2010-05-16 22:49:58 +08:00
|
|
|
WARN_ON(cur_trans != info->running_transaction);
|
2011-04-12 03:45:29 +08:00
|
|
|
WARN_ON(atomic_read(&cur_trans->num_writers) < 1);
|
|
|
|
atomic_dec(&cur_trans->num_writers);
|
2013-05-15 15:48:27 +08:00
|
|
|
extwriter_counter_dec(cur_trans, trans->type);
|
2008-06-26 04:01:31 +08:00
|
|
|
|
2018-02-26 23:15:17 +08:00
|
|
|
cond_wake_up(&cur_trans->writer_wait);
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
2009-09-12 04:12:44 +08:00
|
|
|
|
|
|
|
if (current->journal_info == trans)
|
|
|
|
current->journal_info = NULL;
|
2008-07-30 04:15:18 +08:00
|
|
|
|
2009-11-12 17:36:34 +08:00
|
|
|
if (throttle)
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_run_delayed_iputs(info);
|
2009-11-12 17:36:34 +08:00
|
|
|
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(trans) ||
|
2016-06-23 06:54:23 +08:00
|
|
|
test_bit(BTRFS_FS_STATE_ERROR, &info->fs_state)) {
|
2013-09-28 04:32:39 +08:00
|
|
|
wake_up_process(info->transaction_kthread);
|
btrfs: return EROFS for BTRFS_FS_STATE_ERROR cases
Eric reported seeing this message while running generic/475
BTRFS: error (device dm-3) in btrfs_sync_log:3084: errno=-117 Filesystem corrupted
Full stack trace:
BTRFS: error (device dm-0) in btrfs_commit_transaction:2323: errno=-5 IO failure (Error while writing out transaction)
BTRFS info (device dm-0): forced readonly
BTRFS warning (device dm-0): Skipping commit of aborted transaction.
------------[ cut here ]------------
BTRFS: error (device dm-0) in cleanup_transaction:1894: errno=-5 IO failure
BTRFS: Transaction aborted (error -117)
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c6480 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c6488 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c6490 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c6498 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c64a0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c64a8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c64b0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c64b8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3555 rw 0,0 sector 0x1c64c0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3572 rw 0,0 sector 0x1b85e8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3572 rw 0,0 sector 0x1b85f0 len 4096 err no 10
WARNING: CPU: 3 PID: 23985 at fs/btrfs/tree-log.c:3084 btrfs_sync_log+0xbc8/0xd60 [btrfs]
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d4288 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d4290 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d4298 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42a0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42a8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42b0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42b8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42c0 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42c8 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 3548 rw 0,0 sector 0x1d42d0 len 4096 err no 10
CPU: 3 PID: 23985 Comm: fsstress Tainted: G W L 5.8.0-rc4-default+ #1181
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
RIP: 0010:btrfs_sync_log+0xbc8/0xd60 [btrfs]
RSP: 0018:ffff909a44d17bd0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
RDX: ffff8f3be41cb940 RSI: ffffffffb0108d2b RDI: ffffffffb0108ff7
RBP: ffff909a44d17e70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000037988 R12: ffff8f3bd20e4000
R13: ffff8f3bd20e4428 R14: 00000000ffffff8b R15: ffff909a44d17c70
FS: 00007f6a6ed3fb80(0000) GS:ffff8f3c3dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6a6ed3e000 CR3: 00000000525c0003 CR4: 0000000000160ee0
Call Trace:
? finish_wait+0x90/0x90
? __mutex_unlock_slowpath+0x45/0x2a0
? lock_acquire+0xa3/0x440
? lockref_put_or_lock+0x9/0x30
? dput+0x20/0x4a0
? dput+0x20/0x4a0
? do_raw_spin_unlock+0x4b/0xc0
? _raw_spin_unlock+0x1f/0x30
btrfs_sync_file+0x335/0x490 [btrfs]
do_fsync+0x38/0x70
__x64_sys_fsync+0x10/0x20
do_syscall_64+0x50/0xe0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f6a6ef1b6e3
Code: Bad RIP value.
RSP: 002b:00007ffd01e20038 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
RAX: ffffffffffffffda RBX: 000000000007a120 RCX: 00007f6a6ef1b6e3
RDX: 00007ffd01e1ffa0 RSI: 00007ffd01e1ffa0 RDI: 0000000000000003
RBP: 0000000000000003 R08: 0000000000000001 R09: 00007ffd01e2004c
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000009f
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
irq event stamp: 0
hardirqs last enabled at (0): [<0000000000000000>] 0x0
hardirqs last disabled at (0): [<ffffffffb007fe0b>] copy_process+0x67b/0x1b00
softirqs last enabled at (0): [<ffffffffb007fe0b>] copy_process+0x67b/0x1b00
softirqs last disabled at (0): [<0000000000000000>] 0x0
---[ end trace af146e0e38433456 ]---
BTRFS: error (device dm-0) in btrfs_sync_log:3084: errno=-117 Filesystem corrupted
This ret came from btrfs_write_marked_extents(). If we get an aborted
transaction via EIO before, we'll see it in btree_write_cache_pages()
and return EUCLEAN, which gets printed as "Filesystem corrupted".
Except we shouldn't be returning EUCLEAN here, we need to be returning
EROFS because EUCLEAN is reserved for actual corruption, not IO errors.
We are inconsistent about our handling of BTRFS_FS_STATE_ERROR
elsewhere, but we want to use EROFS for this particular case. The
original transaction abort has the real error code for why we ended up
with an aborted transaction, all subsequent actions just need to return
EROFS because they may not have a trans handle and have no idea about
the original cause of the abort.
After patch "btrfs: don't WARN if we abort a transaction with EROFS" the
stacktrace will not be dumped either.
Reported-by: Eric Sandeen <esandeen@redhat.com>
CC: stable@vger.kernel.org # 5.4+
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
[ add full test stacktrace ]
Signed-off-by: David Sterba <dsterba@suse.com>
2020-07-21 22:38:37 +08:00
|
|
|
if (TRANS_ABORTED(trans))
|
|
|
|
err = trans->aborted;
|
|
|
|
else
|
|
|
|
err = -EROFS;
|
2013-09-28 04:32:39 +08:00
|
|
|
}
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2012-04-13 04:03:56 +08:00
|
|
|
kmem_cache_free(btrfs_trans_handle_cachep, trans);
|
|
|
|
return err;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
int btrfs_end_transaction(struct btrfs_trans_handle *trans)
|
2008-06-26 04:01:31 +08:00
|
|
|
{
|
2016-09-10 09:39:03 +08:00
|
|
|
return __btrfs_end_transaction(trans, 0);
|
2008-06-26 04:01:31 +08:00
|
|
|
}
|
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
int btrfs_end_transaction_throttle(struct btrfs_trans_handle *trans)
|
2008-06-26 04:01:31 +08:00
|
|
|
{
|
2016-09-10 09:39:03 +08:00
|
|
|
return __btrfs_end_transaction(trans, 1);
|
btrfs: implement delayed inode items operation
Changelog V5 -> V6:
- Fix oom when the memory load is high, by storing the delayed nodes into the
root's radix tree, and letting btrfs inodes go.
Changelog V4 -> V5:
- Fix the race on adding the delayed node to the inode, which is spotted by
Chris Mason.
- Merge Chris Mason's incremental patch into this patch.
- Fix deadlock between readdir() and memory fault, which is reported by
Itaru Kitayama.
Changelog V3 -> V4:
- Fix nested lock, which is reported by Itaru Kitayama, by updating space cache
inode in time.
Changelog V2 -> V3:
- Fix the race between the delayed worker and the task which does delayed items
balance, which is reported by Tsutomu Itoh.
- Modify the patch address David Sterba's comment.
- Fix the bug of the cpu recursion spinlock, reported by Chris Mason
Changelog V1 -> V2:
- break up the global rb-tree, use a list to manage the delayed nodes,
which is created for every directory and file, and used to manage the
delayed directory name index items and the delayed inode item.
- introduce a worker to deal with the delayed nodes.
Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree insertions,
such as inode item, directory name item, directory name index and so on.
If we can do some delayed b+ tree insertion or deletion, we can improve the
performance, so we made this patch which implemented delayed directory name
index insertion/deletion and delayed inode update.
Implementation:
- introduce a delayed root object into the filesystem, that use two lists to
manage the delayed nodes which are created for every file/directory.
One is used to manage all the delayed nodes that have delayed items. And the
other is used to manage the delayed nodes which is waiting to be dealt with
by the work thread.
- Every delayed node has two rb-tree, one is used to manage the directory name
index which is going to be inserted into b+ tree, and the other is used to
manage the directory name index which is going to be deleted from b+ tree.
- introduce a worker to deal with the delayed operation. This worker is used
to deal with the works of the delayed directory name index items insertion
and deletion and the delayed inode update.
When the delayed items is beyond the lower limit, we create works for some
delayed nodes and insert them into the work queue of the worker, and then
go back.
When the delayed items is beyond the upper bound, we create works for all
the delayed nodes that haven't been dealt with, and insert them into the work
queue of the worker, and then wait for that the untreated items is below some
threshold value.
- When we want to insert a directory name index into b+ tree, we just add the
information into the delayed inserting rb-tree.
And then we check the number of the delayed items and do delayed items
balance. (The balance policy is above.)
- When we want to delete a directory name index from the b+ tree, we search it
in the inserting rb-tree at first. If we look it up, just drop it. If not,
add the key of it into the delayed deleting rb-tree.
Similar to the delayed inserting rb-tree, we also check the number of the
delayed items and do delayed items balance.
(The same to inserting manipulation)
- When we want to update the metadata of some inode, we cached the data of the
inode into the delayed node. the worker will flush it into the b+ tree after
dealing with the delayed insertion and deletion.
- We will move the delayed node to the tail of the list after we access the
delayed node, By this way, we can cache more delayed items and merge more
inode updates.
- If we want to commit transaction, we will deal with all the delayed node.
- the delayed node will be freed when we free the btrfs inode.
- Before we log the inode items, we commit all the directory name index items
and the delayed inode update.
I did a quick test by the benchmark tool[1] and found we can improve the
performance of file creation by ~15%, and file deletion by ~20%.
Before applying this patch:
Create files:
Total files: 50000
Total time: 1.096108
Average time: 0.000022
Delete files:
Total files: 50000
Total time: 1.510403
Average time: 0.000030
After applying this patch:
Create files:
Total files: 50000
Total time: 0.932899
Average time: 0.000019
Delete files:
Total files: 50000
Total time: 1.215732
Average time: 0.000024
[1] http://marc.info/?l=linux-btrfs&m=128212635122920&q=p3
Many thanks for Kitayama-san's help!
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Reviewed-by: David Sterba <dave@jikos.cz>
Tested-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Tested-by: Itaru Kitayama <kitayama@cl.bb4u.ne.jp>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-04-22 18:12:22 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* when btree blocks are allocated, they have some corresponding bits set for
|
|
|
|
* them in one of two extent_io trees. This is used to make sure all of
|
2009-10-14 01:29:19 +08:00
|
|
|
* those extents are sent to disk but does not wait on them
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
int btrfs_write_marked_extents(struct btrfs_fs_info *fs_info,
|
2009-11-12 17:33:26 +08:00
|
|
|
struct extent_io_tree *dirty_pages, int mark)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
2008-08-16 03:34:15 +08:00
|
|
|
int err = 0;
|
2007-04-28 21:29:35 +08:00
|
|
|
int werr = 0;
|
2016-06-23 06:54:23 +08:00
|
|
|
struct address_space *mapping = fs_info->btree_inode->i_mapping;
|
2012-09-28 05:07:30 +08:00
|
|
|
struct extent_state *cached_state = NULL;
|
2008-08-16 03:34:15 +08:00
|
|
|
u64 start = 0;
|
2007-10-16 04:14:19 +08:00
|
|
|
u64 end;
|
2007-04-28 21:29:35 +08:00
|
|
|
|
2017-08-22 05:49:59 +08:00
|
|
|
atomic_inc(&BTRFS_I(fs_info->btree_inode)->sync_writers);
|
2011-09-27 01:58:47 +08:00
|
|
|
while (!find_first_extent_bit(dirty_pages, start, &start, &end,
|
2012-09-28 05:07:30 +08:00
|
|
|
mark, &cached_state)) {
|
2014-10-13 19:28:37 +08:00
|
|
|
bool wait_writeback = false;
|
|
|
|
|
|
|
|
err = convert_extent_bit(dirty_pages, start, end,
|
|
|
|
EXTENT_NEED_WAIT,
|
2016-04-27 05:54:39 +08:00
|
|
|
mark, &cached_state);
|
2014-10-13 19:28:37 +08:00
|
|
|
/*
|
|
|
|
* convert_extent_bit can return -ENOMEM, which is most of the
|
|
|
|
* time a temporary error. So when it happens, ignore the error
|
|
|
|
* and wait for writeback of this range to finish - because we
|
|
|
|
* failed to set the bit EXTENT_NEED_WAIT for the range, a call
|
2016-09-10 08:42:44 +08:00
|
|
|
* to __btrfs_wait_marked_extents() would not know that
|
|
|
|
* writeback for this range started and therefore wouldn't
|
|
|
|
* wait for it to finish - we don't want to commit a
|
|
|
|
* superblock that points to btree nodes/leafs for which
|
|
|
|
* writeback hasn't finished yet (and without errors).
|
2014-10-13 19:28:37 +08:00
|
|
|
* We cleanup any entries left in the io tree when committing
|
2019-03-25 20:31:24 +08:00
|
|
|
* the transaction (through extent_io_tree_release()).
|
2014-10-13 19:28:37 +08:00
|
|
|
*/
|
|
|
|
if (err == -ENOMEM) {
|
|
|
|
err = 0;
|
|
|
|
wait_writeback = true;
|
|
|
|
}
|
|
|
|
if (!err)
|
|
|
|
err = filemap_fdatawrite_range(mapping, start, end);
|
2011-09-27 01:58:47 +08:00
|
|
|
if (err)
|
|
|
|
werr = err;
|
2014-10-13 19:28:37 +08:00
|
|
|
else if (wait_writeback)
|
|
|
|
werr = filemap_fdatawait_range(mapping, start, end);
|
2014-10-13 19:28:38 +08:00
|
|
|
free_extent_state(cached_state);
|
2014-10-13 19:28:37 +08:00
|
|
|
cached_state = NULL;
|
2011-09-27 01:58:47 +08:00
|
|
|
cond_resched();
|
|
|
|
start = end + 1;
|
2007-04-28 21:29:35 +08:00
|
|
|
}
|
2017-08-22 05:49:59 +08:00
|
|
|
atomic_dec(&BTRFS_I(fs_info->btree_inode)->sync_writers);
|
2009-10-14 01:29:19 +08:00
|
|
|
return werr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* when btree blocks are allocated, they have some corresponding bits set for
|
|
|
|
* them in one of two extent_io trees. This is used to make sure all of
|
|
|
|
* those extents are on disk for transaction or log commit. We wait
|
|
|
|
* on all the pages and clear them from the dirty pages state tree
|
|
|
|
*/
|
2016-09-10 08:42:44 +08:00
|
|
|
static int __btrfs_wait_marked_extents(struct btrfs_fs_info *fs_info,
|
|
|
|
struct extent_io_tree *dirty_pages)
|
2009-10-14 01:29:19 +08:00
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
int werr = 0;
|
2016-06-23 06:54:23 +08:00
|
|
|
struct address_space *mapping = fs_info->btree_inode->i_mapping;
|
2012-09-28 05:07:30 +08:00
|
|
|
struct extent_state *cached_state = NULL;
|
2009-10-14 01:29:19 +08:00
|
|
|
u64 start = 0;
|
|
|
|
u64 end;
|
2008-08-16 03:34:15 +08:00
|
|
|
|
2011-09-27 01:58:47 +08:00
|
|
|
while (!find_first_extent_bit(dirty_pages, start, &start, &end,
|
2012-09-28 05:07:30 +08:00
|
|
|
EXTENT_NEED_WAIT, &cached_state)) {
|
2014-10-13 19:28:37 +08:00
|
|
|
/*
|
|
|
|
* Ignore -ENOMEM errors returned by clear_extent_bit().
|
|
|
|
* When committing the transaction, we'll remove any entries
|
|
|
|
* left in the io tree. For a log commit, we don't remove them
|
|
|
|
* after committing the log because the tree can be accessed
|
|
|
|
* concurrently - we do it only at transaction commit time when
|
2019-03-25 20:31:24 +08:00
|
|
|
* it's safe to do it (through extent_io_tree_release()).
|
2014-10-13 19:28:37 +08:00
|
|
|
*/
|
|
|
|
err = clear_extent_bit(dirty_pages, start, end,
|
2017-10-31 23:37:52 +08:00
|
|
|
EXTENT_NEED_WAIT, 0, 0, &cached_state);
|
2014-10-13 19:28:37 +08:00
|
|
|
if (err == -ENOMEM)
|
|
|
|
err = 0;
|
|
|
|
if (!err)
|
|
|
|
err = filemap_fdatawait_range(mapping, start, end);
|
2011-09-27 01:58:47 +08:00
|
|
|
if (err)
|
|
|
|
werr = err;
|
2014-10-13 19:28:38 +08:00
|
|
|
free_extent_state(cached_state);
|
|
|
|
cached_state = NULL;
|
2011-09-27 01:58:47 +08:00
|
|
|
cond_resched();
|
|
|
|
start = end + 1;
|
2008-08-16 03:34:15 +08:00
|
|
|
}
|
2007-04-28 21:29:35 +08:00
|
|
|
if (err)
|
|
|
|
werr = err;
|
2016-09-10 08:42:44 +08:00
|
|
|
return werr;
|
|
|
|
}
|
Btrfs: be aware of btree inode write errors to avoid fs corruption
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit the running transaction. If this happens,
we might have no way of knowing that such error happened when we are
committing the transaction - because the pages might no longer be
marked dirty nor tagged for writeback (if a subsequent modification
to the extent buffer didn't happen before the transaction commit) which
makes filemap_fdata[write|wait]_range unable to find such pages (even
if they're marked with SetPageError).
So if this happens we must abort the transaction, otherwise we commit
a super block with btree roots that point to btree nodes/leafs whose
content on disk is invalid - either garbage or the content of some
node/leaf from a past generation that got cowed or deleted and is no
longer valid (for this later case we end up getting error messages like
"parent transid verify failed on 10826481664 wanted 25748 found 29562"
when reading btree nodes/leafs from disk).
Note that setting and checking AS_EIO/AS_ENOSPC in the btree inode's
i_mapping would not be enough because we need to distinguish between
log tree extents (not fatal) vs non-log tree extents (fatal) and
because the next call to filemap_fdatawait_range() will catch and clear
such errors in the mapping - and that call might be from a log sync and
not from a transaction commit, which means we would not know about the
error at transaction commit time. Also, checking for the eb flag
EXTENT_BUFFER_IOERR at transaction commit time isn't done and would
not be completely reliable, as the eb might be removed from memory and
read back when trying to get it, which clears that flag right before
reading the eb's pages from disk, making us not know about the previous
write error.
Using the new 3 flags for the btree inode also makes us achieve the
goal of AS_EIO/AS_ENOSPC when writepages() returns success, started
writeback for all dirty pages and before filemap_fdatawait_range() is
called, the writeback for all dirty pages had already finished with
errors - because we were not using AS_EIO/AS_ENOSPC,
filemap_fdatawait_range() would return success, as it could not know
that writeback errors happened (the pages were no longer tagged for
writeback).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-26 19:25:56 +08:00
|
|
|
|
2019-09-12 00:42:38 +08:00
|
|
|
static int btrfs_wait_extents(struct btrfs_fs_info *fs_info,
|
2016-09-10 08:42:44 +08:00
|
|
|
struct extent_io_tree *dirty_pages)
|
|
|
|
{
|
|
|
|
bool errors = false;
|
|
|
|
int err;
|
Btrfs: be aware of btree inode write errors to avoid fs corruption
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit the running transaction. If this happens,
we might have no way of knowing that such error happened when we are
committing the transaction - because the pages might no longer be
marked dirty nor tagged for writeback (if a subsequent modification
to the extent buffer didn't happen before the transaction commit) which
makes filemap_fdata[write|wait]_range unable to find such pages (even
if they're marked with SetPageError).
So if this happens we must abort the transaction, otherwise we commit
a super block with btree roots that point to btree nodes/leafs whose
content on disk is invalid - either garbage or the content of some
node/leaf from a past generation that got cowed or deleted and is no
longer valid (for this later case we end up getting error messages like
"parent transid verify failed on 10826481664 wanted 25748 found 29562"
when reading btree nodes/leafs from disk).
Note that setting and checking AS_EIO/AS_ENOSPC in the btree inode's
i_mapping would not be enough because we need to distinguish between
log tree extents (not fatal) vs non-log tree extents (fatal) and
because the next call to filemap_fdatawait_range() will catch and clear
such errors in the mapping - and that call might be from a log sync and
not from a transaction commit, which means we would not know about the
error at transaction commit time. Also, checking for the eb flag
EXTENT_BUFFER_IOERR at transaction commit time isn't done and would
not be completely reliable, as the eb might be removed from memory and
read back when trying to get it, which clears that flag right before
reading the eb's pages from disk, making us not know about the previous
write error.
Using the new 3 flags for the btree inode also makes us achieve the
goal of AS_EIO/AS_ENOSPC when writepages() returns success, started
writeback for all dirty pages and before filemap_fdatawait_range() is
called, the writeback for all dirty pages had already finished with
errors - because we were not using AS_EIO/AS_ENOSPC,
filemap_fdatawait_range() would return success, as it could not know
that writeback errors happened (the pages were no longer tagged for
writeback).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-26 19:25:56 +08:00
|
|
|
|
2016-09-10 08:42:44 +08:00
|
|
|
err = __btrfs_wait_marked_extents(fs_info, dirty_pages);
|
|
|
|
if (test_and_clear_bit(BTRFS_FS_BTREE_ERR, &fs_info->flags))
|
|
|
|
errors = true;
|
|
|
|
|
|
|
|
if (errors && !err)
|
|
|
|
err = -EIO;
|
|
|
|
return err;
|
|
|
|
}
|
Btrfs: be aware of btree inode write errors to avoid fs corruption
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit the running transaction. If this happens,
we might have no way of knowing that such error happened when we are
committing the transaction - because the pages might no longer be
marked dirty nor tagged for writeback (if a subsequent modification
to the extent buffer didn't happen before the transaction commit) which
makes filemap_fdata[write|wait]_range unable to find such pages (even
if they're marked with SetPageError).
So if this happens we must abort the transaction, otherwise we commit
a super block with btree roots that point to btree nodes/leafs whose
content on disk is invalid - either garbage or the content of some
node/leaf from a past generation that got cowed or deleted and is no
longer valid (for this later case we end up getting error messages like
"parent transid verify failed on 10826481664 wanted 25748 found 29562"
when reading btree nodes/leafs from disk).
Note that setting and checking AS_EIO/AS_ENOSPC in the btree inode's
i_mapping would not be enough because we need to distinguish between
log tree extents (not fatal) vs non-log tree extents (fatal) and
because the next call to filemap_fdatawait_range() will catch and clear
such errors in the mapping - and that call might be from a log sync and
not from a transaction commit, which means we would not know about the
error at transaction commit time. Also, checking for the eb flag
EXTENT_BUFFER_IOERR at transaction commit time isn't done and would
not be completely reliable, as the eb might be removed from memory and
read back when trying to get it, which clears that flag right before
reading the eb's pages from disk, making us not know about the previous
write error.
Using the new 3 flags for the btree inode also makes us achieve the
goal of AS_EIO/AS_ENOSPC when writepages() returns success, started
writeback for all dirty pages and before filemap_fdatawait_range() is
called, the writeback for all dirty pages had already finished with
errors - because we were not using AS_EIO/AS_ENOSPC,
filemap_fdatawait_range() would return success, as it could not know
that writeback errors happened (the pages were no longer tagged for
writeback).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-26 19:25:56 +08:00
|
|
|
|
2016-09-10 08:42:44 +08:00
|
|
|
int btrfs_wait_tree_log_extents(struct btrfs_root *log_root, int mark)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = log_root->fs_info;
|
|
|
|
struct extent_io_tree *dirty_pages = &log_root->dirty_log_pages;
|
|
|
|
bool errors = false;
|
|
|
|
int err;
|
Btrfs: be aware of btree inode write errors to avoid fs corruption
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit the running transaction. If this happens,
we might have no way of knowing that such error happened when we are
committing the transaction - because the pages might no longer be
marked dirty nor tagged for writeback (if a subsequent modification
to the extent buffer didn't happen before the transaction commit) which
makes filemap_fdata[write|wait]_range unable to find such pages (even
if they're marked with SetPageError).
So if this happens we must abort the transaction, otherwise we commit
a super block with btree roots that point to btree nodes/leafs whose
content on disk is invalid - either garbage or the content of some
node/leaf from a past generation that got cowed or deleted and is no
longer valid (for this later case we end up getting error messages like
"parent transid verify failed on 10826481664 wanted 25748 found 29562"
when reading btree nodes/leafs from disk).
Note that setting and checking AS_EIO/AS_ENOSPC in the btree inode's
i_mapping would not be enough because we need to distinguish between
log tree extents (not fatal) vs non-log tree extents (fatal) and
because the next call to filemap_fdatawait_range() will catch and clear
such errors in the mapping - and that call might be from a log sync and
not from a transaction commit, which means we would not know about the
error at transaction commit time. Also, checking for the eb flag
EXTENT_BUFFER_IOERR at transaction commit time isn't done and would
not be completely reliable, as the eb might be removed from memory and
read back when trying to get it, which clears that flag right before
reading the eb's pages from disk, making us not know about the previous
write error.
Using the new 3 flags for the btree inode also makes us achieve the
goal of AS_EIO/AS_ENOSPC when writepages() returns success, started
writeback for all dirty pages and before filemap_fdatawait_range() is
called, the writeback for all dirty pages had already finished with
errors - because we were not using AS_EIO/AS_ENOSPC,
filemap_fdatawait_range() would return success, as it could not know
that writeback errors happened (the pages were no longer tagged for
writeback).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-26 19:25:56 +08:00
|
|
|
|
2016-09-10 08:42:44 +08:00
|
|
|
ASSERT(log_root->root_key.objectid == BTRFS_TREE_LOG_OBJECTID);
|
|
|
|
|
|
|
|
err = __btrfs_wait_marked_extents(fs_info, dirty_pages);
|
|
|
|
if ((mark & EXTENT_DIRTY) &&
|
|
|
|
test_and_clear_bit(BTRFS_FS_LOG1_ERR, &fs_info->flags))
|
|
|
|
errors = true;
|
|
|
|
|
|
|
|
if ((mark & EXTENT_NEW) &&
|
|
|
|
test_and_clear_bit(BTRFS_FS_LOG2_ERR, &fs_info->flags))
|
|
|
|
errors = true;
|
|
|
|
|
|
|
|
if (errors && !err)
|
|
|
|
err = -EIO;
|
|
|
|
return err;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
|
|
|
|
2009-10-14 01:29:19 +08:00
|
|
|
/*
|
2018-02-07 23:55:38 +08:00
|
|
|
* When btree blocks are allocated the corresponding extents are marked dirty.
|
|
|
|
* This function ensures such extents are persisted on disk for transaction or
|
|
|
|
* log commit.
|
|
|
|
*
|
|
|
|
* @trans: transaction whose dirty pages we'd like to write
|
2009-10-14 01:29:19 +08:00
|
|
|
*/
|
2018-02-07 23:55:50 +08:00
|
|
|
static int btrfs_write_and_wait_transaction(struct btrfs_trans_handle *trans)
|
2009-10-14 01:29:19 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int ret2;
|
2018-02-07 23:55:38 +08:00
|
|
|
struct extent_io_tree *dirty_pages = &trans->transaction->dirty_pages;
|
2018-02-07 23:55:50 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2013-05-28 18:05:39 +08:00
|
|
|
struct blk_plug plug;
|
2009-10-14 01:29:19 +08:00
|
|
|
|
2013-05-28 18:05:39 +08:00
|
|
|
blk_start_plug(&plug);
|
2018-02-07 23:55:38 +08:00
|
|
|
ret = btrfs_write_marked_extents(fs_info, dirty_pages, EXTENT_DIRTY);
|
2013-05-28 18:05:39 +08:00
|
|
|
blk_finish_plug(&plug);
|
2016-09-10 08:42:44 +08:00
|
|
|
ret2 = btrfs_wait_extents(fs_info, dirty_pages);
|
2011-11-05 00:29:37 +08:00
|
|
|
|
2019-03-25 20:31:24 +08:00
|
|
|
extent_io_tree_release(&trans->transaction->dirty_pages);
|
2018-02-07 23:55:38 +08:00
|
|
|
|
2011-11-05 00:29:37 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-02-07 23:55:38 +08:00
|
|
|
else if (ret2)
|
2011-11-05 00:29:37 +08:00
|
|
|
return ret2;
|
2018-02-07 23:55:38 +08:00
|
|
|
else
|
|
|
|
return 0;
|
2008-09-12 04:17:57 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* this is used to update the root pointer in the tree of tree roots.
|
|
|
|
*
|
|
|
|
* But, in the case of the extent allocation tree, updating the root
|
|
|
|
* pointer may allocate blocks which may change the root of the extent
|
|
|
|
* allocation tree.
|
|
|
|
*
|
|
|
|
* So, this loops and repeats and makes sure the cowonly root didn't
|
|
|
|
* change while the root pointer was being updated in the metadata.
|
|
|
|
*/
|
2008-03-25 03:01:56 +08:00
|
|
|
static int update_cowonly_root(struct btrfs_trans_handle *trans,
|
|
|
|
struct btrfs_root *root)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2008-03-25 03:01:56 +08:00
|
|
|
u64 old_root_bytenr;
|
2009-11-12 17:36:50 +08:00
|
|
|
u64 old_root_used;
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
struct btrfs_root *tree_root = fs_info->tree_root;
|
2007-03-23 03:59:16 +08:00
|
|
|
|
2009-11-12 17:36:50 +08:00
|
|
|
old_root_used = btrfs_root_used(&root->root_item);
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2009-01-06 10:25:51 +08:00
|
|
|
while (1) {
|
2008-03-25 03:01:56 +08:00
|
|
|
old_root_bytenr = btrfs_root_bytenr(&root->root_item);
|
2009-11-12 17:36:50 +08:00
|
|
|
if (old_root_bytenr == root->node->start &&
|
2015-03-14 04:40:45 +08:00
|
|
|
old_root_used == btrfs_root_used(&root->root_item))
|
2007-03-23 03:59:16 +08:00
|
|
|
break;
|
2008-10-30 23:23:27 +08:00
|
|
|
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
btrfs_set_root_node(&root->root_item, root->node);
|
2007-03-23 03:59:16 +08:00
|
|
|
ret = btrfs_update_root(trans, tree_root,
|
2008-03-25 03:01:56 +08:00
|
|
|
&root->root_key,
|
|
|
|
&root->root_item);
|
2012-03-02 00:24:58 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2009-11-12 17:36:50 +08:00
|
|
|
old_root_used = btrfs_root_used(&root->root_item);
|
2008-03-25 03:01:56 +08:00
|
|
|
}
|
2009-07-30 21:40:40 +08:00
|
|
|
|
2008-03-25 03:01:56 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* update all the cowonly tree roots on disk
|
2012-03-02 00:24:58 +08:00
|
|
|
*
|
|
|
|
* The error handling in this function may not be obvious. Any of the
|
|
|
|
* failures will cause the file system to go offline. We still need
|
|
|
|
* to clean up the delayed refs.
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2018-02-07 23:55:45 +08:00
|
|
|
static noinline int commit_cowonly_roots(struct btrfs_trans_handle *trans)
|
2008-03-25 03:01:56 +08:00
|
|
|
{
|
2018-02-07 23:55:45 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2015-03-14 04:40:45 +08:00
|
|
|
struct list_head *dirty_bgs = &trans->transaction->dirty_bgs;
|
2015-04-07 03:46:08 +08:00
|
|
|
struct list_head *io_bgs = &trans->transaction->io_bgs;
|
2008-03-25 03:01:56 +08:00
|
|
|
struct list_head *next;
|
2008-10-30 02:49:05 +08:00
|
|
|
struct extent_buffer *eb;
|
2009-03-13 22:10:06 +08:00
|
|
|
int ret;
|
2008-10-30 02:49:05 +08:00
|
|
|
|
|
|
|
eb = btrfs_lock_root_node(fs_info->tree_root);
|
2012-03-02 00:24:58 +08:00
|
|
|
ret = btrfs_cow_block(trans, fs_info->tree_root, eb, NULL,
|
2020-08-20 23:46:03 +08:00
|
|
|
0, &eb, BTRFS_NESTING_COW);
|
2008-10-30 02:49:05 +08:00
|
|
|
btrfs_tree_unlock(eb);
|
|
|
|
free_extent_buffer(eb);
|
2008-03-25 03:01:56 +08:00
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2012-03-02 00:24:58 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2008-10-30 23:23:27 +08:00
|
|
|
|
2019-03-20 23:50:38 +08:00
|
|
|
ret = btrfs_run_dev_stats(trans);
|
2013-09-28 04:38:20 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-03-20 23:51:44 +08:00
|
|
|
ret = btrfs_run_dev_replace(trans);
|
2013-09-28 04:38:20 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-07-18 14:45:40 +08:00
|
|
|
ret = btrfs_run_qgroups(trans);
|
2013-09-28 04:38:20 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-06-14 22:37:44 +08:00
|
|
|
|
2019-03-20 19:02:55 +08:00
|
|
|
ret = btrfs_setup_space_cache(trans);
|
2015-03-03 05:37:31 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2012-06-14 22:37:44 +08:00
|
|
|
/* run_qgroups might have added some more refs */
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2013-09-28 04:38:20 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2015-03-14 04:40:45 +08:00
|
|
|
again:
|
2009-01-06 10:25:51 +08:00
|
|
|
while (!list_empty(&fs_info->dirty_cowonly_roots)) {
|
2016-06-23 06:54:24 +08:00
|
|
|
struct btrfs_root *root;
|
2008-03-25 03:01:56 +08:00
|
|
|
next = fs_info->dirty_cowonly_roots.next;
|
|
|
|
list_del_init(next);
|
|
|
|
root = list_entry(next, struct btrfs_root, dirty_list);
|
2014-12-17 00:54:43 +08:00
|
|
|
clear_bit(BTRFS_ROOT_DIRTY, &root->state);
|
2008-10-30 23:23:27 +08:00
|
|
|
|
2014-03-14 03:42:13 +08:00
|
|
|
if (root != fs_info->extent_root)
|
|
|
|
list_add_tail(&root->dirty_list,
|
|
|
|
&trans->transaction->switch_commits);
|
2012-03-02 00:24:58 +08:00
|
|
|
ret = update_cowonly_root(trans, root);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2015-03-14 04:40:45 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
2009-07-30 21:40:40 +08:00
|
|
|
|
2015-04-07 03:46:08 +08:00
|
|
|
while (!list_empty(dirty_bgs) || !list_empty(io_bgs)) {
|
2019-03-20 19:04:08 +08:00
|
|
|
ret = btrfs_write_dirty_block_groups(trans);
|
2015-03-14 04:40:45 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2015-03-14 04:40:45 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!list_empty(&fs_info->dirty_cowonly_roots))
|
|
|
|
goto again;
|
|
|
|
|
2014-03-14 03:42:13 +08:00
|
|
|
list_add_tail(&fs_info->extent_root->dirty_list,
|
|
|
|
&trans->transaction->switch_commits);
|
2018-08-24 23:41:17 +08:00
|
|
|
|
|
|
|
/* Update dev-replace pointer once everything is committed */
|
|
|
|
fs_info->dev_replace.committed_cursor_left =
|
|
|
|
fs_info->dev_replace.cursor_left_last_write_of_item;
|
2012-11-06 20:15:27 +08:00
|
|
|
|
2007-03-23 03:59:16 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* dead roots are old snapshots that need to be deleted. This allocates
|
|
|
|
* a dirty root struct and adds it into the list of dead roots that need to
|
|
|
|
* be deleted
|
|
|
|
*/
|
2013-07-26 03:11:47 +08:00
|
|
|
void btrfs_add_dead_root(struct btrfs_root *root)
|
2007-06-23 02:16:25 +08:00
|
|
|
{
|
2016-06-23 06:54:23 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
|
|
|
|
spin_lock(&fs_info->trans_lock);
|
2020-02-15 05:11:44 +08:00
|
|
|
if (list_empty(&root->root_list)) {
|
|
|
|
btrfs_grab_root(root);
|
2016-06-23 06:54:23 +08:00
|
|
|
list_add_tail(&root->root_list, &fs_info->dead_roots);
|
2020-02-15 05:11:44 +08:00
|
|
|
}
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2007-06-23 02:16:25 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
* update all the cowonly tree roots on disk
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2018-02-07 23:55:44 +08:00
|
|
|
static noinline int commit_fs_roots(struct btrfs_trans_handle *trans)
|
2007-04-09 22:42:37 +08:00
|
|
|
{
|
2018-02-07 23:55:44 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2007-04-09 22:42:37 +08:00
|
|
|
struct btrfs_root *gang[8];
|
|
|
|
int i;
|
|
|
|
int ret;
|
2007-06-23 02:16:25 +08:00
|
|
|
int err = 0;
|
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock(&fs_info->fs_roots_radix_lock);
|
2009-01-06 10:25:51 +08:00
|
|
|
while (1) {
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
ret = radix_tree_gang_lookup_tag(&fs_info->fs_roots_radix,
|
|
|
|
(void **)gang, 0,
|
2007-04-09 22:42:37 +08:00
|
|
|
ARRAY_SIZE(gang),
|
|
|
|
BTRFS_ROOT_TRANS_TAG);
|
|
|
|
if (ret == 0)
|
|
|
|
break;
|
|
|
|
for (i = 0; i < ret; i++) {
|
2016-06-21 22:40:19 +08:00
|
|
|
struct btrfs_root *root = gang[i];
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
radix_tree_tag_clear(&fs_info->fs_roots_radix,
|
|
|
|
(unsigned long)root->root_key.objectid,
|
|
|
|
BTRFS_ROOT_TRANS_TAG);
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_unlock(&fs_info->fs_roots_radix_lock);
|
2008-07-29 03:32:19 +08:00
|
|
|
|
2008-09-06 04:13:11 +08:00
|
|
|
btrfs_free_log(trans, root);
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
btrfs_update_reloc_root(trans, root);
|
2008-07-31 04:29:20 +08:00
|
|
|
|
2011-04-20 10:33:24 +08:00
|
|
|
btrfs_save_ino_cache(root, trans);
|
|
|
|
|
2011-11-15 09:48:06 +08:00
|
|
|
/* see comments in should_cow_block() */
|
2014-04-02 19:51:05 +08:00
|
|
|
clear_bit(BTRFS_ROOT_FORCE_COW, &root->state);
|
2014-06-11 04:06:56 +08:00
|
|
|
smp_mb__after_atomic();
|
2011-11-15 09:48:06 +08:00
|
|
|
|
2009-06-16 08:01:02 +08:00
|
|
|
if (root->commit_root != root->node) {
|
2014-03-14 03:42:13 +08:00
|
|
|
list_add_tail(&root->dirty_list,
|
|
|
|
&trans->transaction->switch_commits);
|
2009-06-16 08:01:02 +08:00
|
|
|
btrfs_set_root_node(&root->root_item,
|
|
|
|
root->node);
|
|
|
|
}
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
|
|
|
err = btrfs_update_root(trans, fs_info->tree_root,
|
2007-04-09 22:42:37 +08:00
|
|
|
&root->root_key,
|
|
|
|
&root->root_item);
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock(&fs_info->fs_roots_radix_lock);
|
2007-06-23 02:16:25 +08:00
|
|
|
if (err)
|
|
|
|
break;
|
btrfs: qgroup: Split meta rsv type into meta_prealloc and meta_pertrans
Btrfs uses 2 different methods to reseve metadata qgroup space.
1) Reserve at btrfs_start_transaction() time
This is quite straightforward, caller will use the trans handler
allocated to modify b-trees.
In this case, reserved metadata should be kept until qgroup numbers
are updated.
2) Reserve by using block_rsv first, and later btrfs_join_transaction()
This is more complicated, caller will reserve space using block_rsv
first, and then later call btrfs_join_transaction() to get a trans
handle.
In this case, before we modify trees, the reserved space can be
modified on demand, and after btrfs_join_transaction(), such reserved
space should also be kept until qgroup numbers are updated.
Since these two types behave differently, split the original "META"
reservation type into 2 sub-types:
META_PERTRANS:
For above case 1)
META_PREALLOC:
For reservations that happened before btrfs_join_transaction() of
case 2)
NOTE: This patch will only convert existing qgroup meta reservation
callers according to its situation, not ensuring all callers are at
correct timing.
Such fix will be added in later patches.
Signed-off-by: Qu Wenruo <wqu@suse.com>
[ update comments ]
Signed-off-by: David Sterba <dsterba@suse.com>
2017-12-12 15:34:29 +08:00
|
|
|
btrfs_qgroup_free_meta_all_pertrans(root);
|
2007-04-09 22:42:37 +08:00
|
|
|
}
|
|
|
|
}
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_unlock(&fs_info->fs_roots_radix_lock);
|
2007-06-23 02:16:25 +08:00
|
|
|
return err;
|
2007-04-09 22:42:37 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
2013-02-01 02:21:12 +08:00
|
|
|
* defrag a given btree.
|
|
|
|
* Every leaf in the btree is read and defragged.
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2013-02-01 02:21:12 +08:00
|
|
|
int btrfs_defrag_root(struct btrfs_root *root)
|
2007-08-11 02:06:19 +08:00
|
|
|
{
|
|
|
|
struct btrfs_fs_info *info = root->fs_info;
|
|
|
|
struct btrfs_trans_handle *trans;
|
2010-05-16 22:49:58 +08:00
|
|
|
int ret;
|
2007-08-11 02:06:19 +08:00
|
|
|
|
2014-04-02 19:51:05 +08:00
|
|
|
if (test_and_set_bit(BTRFS_ROOT_DEFRAG_RUNNING, &root->state))
|
2007-08-11 02:06:19 +08:00
|
|
|
return 0;
|
2010-05-16 22:49:58 +08:00
|
|
|
|
2007-10-16 04:17:34 +08:00
|
|
|
while (1) {
|
2010-05-16 22:49:58 +08:00
|
|
|
trans = btrfs_start_transaction(root, 0);
|
|
|
|
if (IS_ERR(trans))
|
|
|
|
return PTR_ERR(trans);
|
|
|
|
|
2013-02-01 02:21:12 +08:00
|
|
|
ret = btrfs_defrag_leaves(trans, root);
|
2010-05-16 22:49:58 +08:00
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_end_transaction(trans);
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_btree_balance_dirty(info);
|
2007-08-11 02:06:19 +08:00
|
|
|
cond_resched();
|
|
|
|
|
2016-09-20 22:05:02 +08:00
|
|
|
if (btrfs_fs_closing(info) || ret != -EAGAIN)
|
2007-08-11 02:06:19 +08:00
|
|
|
break;
|
2013-02-10 07:38:06 +08:00
|
|
|
|
2016-09-20 22:05:02 +08:00
|
|
|
if (btrfs_defrag_cancelled(info)) {
|
|
|
|
btrfs_debug(info, "defrag_root cancelled");
|
2013-02-10 07:38:06 +08:00
|
|
|
ret = -EAGAIN;
|
|
|
|
break;
|
|
|
|
}
|
2007-08-11 02:06:19 +08:00
|
|
|
}
|
2014-04-02 19:51:05 +08:00
|
|
|
clear_bit(BTRFS_ROOT_DEFRAG_RUNNING, &root->state);
|
2010-05-16 22:49:58 +08:00
|
|
|
return ret;
|
2007-08-11 02:06:19 +08:00
|
|
|
}
|
|
|
|
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
/*
|
|
|
|
* Do all special snapshot related qgroup dirty hack.
|
|
|
|
*
|
|
|
|
* Will do all needed qgroup inherit and dirty hack like switch commit
|
|
|
|
* roots inside one transaction and write all btree into disk, to make
|
|
|
|
* qgroup works.
|
|
|
|
*/
|
|
|
|
static int qgroup_account_snapshot(struct btrfs_trans_handle *trans,
|
|
|
|
struct btrfs_root *src,
|
|
|
|
struct btrfs_root *parent,
|
|
|
|
struct btrfs_qgroup_inherit *inherit,
|
|
|
|
u64 dst_objectid)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = src->fs_info;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Save some performance in the case that qgroups are not
|
|
|
|
* enabled. If this check races with the ioctl, rescan will
|
|
|
|
* kick in anyway.
|
|
|
|
*/
|
2017-02-13 21:07:02 +08:00
|
|
|
if (!test_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags))
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-12-19 15:44:54 +08:00
|
|
|
/*
|
2018-11-28 19:05:13 +08:00
|
|
|
* Ensure dirty @src will be committed. Or, after coming
|
2017-12-19 15:44:54 +08:00
|
|
|
* commit_fs_roots() and switch_commit_roots(), any dirty but not
|
|
|
|
* recorded root will never be updated again, causing an outdated root
|
|
|
|
* item.
|
|
|
|
*/
|
|
|
|
record_root_in_trans(trans, src, 1);
|
|
|
|
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
/*
|
|
|
|
* We are going to commit transaction, see btrfs_commit_transaction()
|
|
|
|
* comment for reason locking tree_log_mutex
|
|
|
|
*/
|
|
|
|
mutex_lock(&fs_info->tree_log_mutex);
|
|
|
|
|
2018-02-07 23:55:44 +08:00
|
|
|
ret = commit_fs_roots(trans);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2018-03-15 22:00:25 +08:00
|
|
|
ret = btrfs_qgroup_account_extents(trans);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Now qgroup are all updated, we can inherit it to new qgroups */
|
2018-07-18 14:45:41 +08:00
|
|
|
ret = btrfs_qgroup_inherit(trans, src->root_key.objectid, dst_objectid,
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
inherit);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we do a simplified commit transaction, which will:
|
|
|
|
* 1) commit all subvolume and extent tree
|
|
|
|
* To ensure all subvolume and extent tree have a valid
|
|
|
|
* commit_root to accounting later insert_dir_item()
|
|
|
|
* 2) write all btree blocks onto disk
|
|
|
|
* This is to make sure later btree modification will be cowed
|
|
|
|
* Or commit_root can be populated and cause wrong qgroup numbers
|
|
|
|
* In this simplified commit, we don't really care about other trees
|
|
|
|
* like chunk and root tree, as they won't affect qgroup.
|
|
|
|
* And we don't write super to avoid half committed status.
|
|
|
|
*/
|
2018-02-07 23:55:45 +08:00
|
|
|
ret = commit_cowonly_roots(trans);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-01-17 22:12:45 +08:00
|
|
|
switch_commit_roots(trans);
|
2018-02-07 23:55:50 +08:00
|
|
|
ret = btrfs_write_and_wait_transaction(trans);
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
if (ret)
|
2016-06-18 00:15:25 +08:00
|
|
|
btrfs_handle_fs_error(fs_info, ret,
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
"Error while writing out transaction for qgroup");
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&fs_info->tree_log_mutex);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Force parent root to be updated, as we recorded it before so its
|
|
|
|
* last_trans == cur_transid.
|
|
|
|
* Or it won't be committed again onto disk after later
|
|
|
|
* insert_dir_item()
|
|
|
|
*/
|
|
|
|
if (!ret)
|
|
|
|
record_root_in_trans(trans, parent, 1);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* new snapshots need to be created at a very specific time in the
|
2013-03-04 17:44:29 +08:00
|
|
|
* transaction commit. This does the actual creation.
|
|
|
|
*
|
|
|
|
* Note:
|
|
|
|
* If the error which may affect the commitment of the current transaction
|
|
|
|
* happens, we should return the error number. If the error which just affect
|
|
|
|
* the creation of the pending snapshots, just return 0.
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2008-02-02 05:35:04 +08:00
|
|
|
static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
|
2008-01-09 04:46:30 +08:00
|
|
|
struct btrfs_pending_snapshot *pending)
|
|
|
|
{
|
2018-02-07 23:55:48 +08:00
|
|
|
|
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2008-01-09 04:46:30 +08:00
|
|
|
struct btrfs_key key;
|
2008-02-02 05:35:04 +08:00
|
|
|
struct btrfs_root_item *new_root_item;
|
2008-01-09 04:46:30 +08:00
|
|
|
struct btrfs_root *tree_root = fs_info->tree_root;
|
|
|
|
struct btrfs_root *root = pending->root;
|
2010-03-16 01:27:13 +08:00
|
|
|
struct btrfs_root *parent_root;
|
2011-09-11 22:52:24 +08:00
|
|
|
struct btrfs_block_rsv *rsv;
|
2010-03-16 01:27:13 +08:00
|
|
|
struct inode *parent_inode;
|
2012-09-06 18:03:32 +08:00
|
|
|
struct btrfs_path *path;
|
|
|
|
struct btrfs_dir_item *dir_item;
|
2010-05-16 22:48:46 +08:00
|
|
|
struct dentry *dentry;
|
2008-01-09 04:46:30 +08:00
|
|
|
struct extent_buffer *tmp;
|
2008-06-26 04:01:30 +08:00
|
|
|
struct extent_buffer *old;
|
vfs: change inode times to use struct timespec64
struct timespec is not y2038 safe. Transition vfs to use
y2038 safe struct timespec64 instead.
The change was made with the help of the following cocinelle
script. This catches about 80% of the changes.
All the header file and logic changes are included in the
first 5 rules. The rest are trivial substitutions.
I avoid changing any of the function signatures or any other
filesystem specific data structures to keep the patch simple
for review.
The script can be a little shorter by combining different cases.
But, this version was sufficient for my usecase.
virtual patch
@ depends on patch @
identifier now;
@@
- struct timespec
+ struct timespec64
current_time ( ... )
{
- struct timespec now = current_kernel_time();
+ struct timespec64 now = current_kernel_time64();
...
- return timespec_trunc(
+ return timespec64_trunc(
... );
}
@ depends on patch @
identifier xtime;
@@
struct \( iattr \| inode \| kstat \) {
...
- struct timespec xtime;
+ struct timespec64 xtime;
...
}
@ depends on patch @
identifier t;
@@
struct inode_operations {
...
int (*update_time) (...,
- struct timespec t,
+ struct timespec64 t,
...);
...
}
@ depends on patch @
identifier t;
identifier fn_update_time =~ "update_time$";
@@
fn_update_time (...,
- struct timespec *t,
+ struct timespec64 *t,
...) { ... }
@ depends on patch @
identifier t;
@@
lease_get_mtime( ... ,
- struct timespec *t
+ struct timespec64 *t
) { ... }
@te depends on patch forall@
identifier ts;
local idexpression struct inode *inode_node;
identifier i_xtime =~ "^i_[acm]time$";
identifier ia_xtime =~ "^ia_[acm]time$";
identifier fn_update_time =~ "update_time$";
identifier fn;
expression e, E3;
local idexpression struct inode *node1;
local idexpression struct inode *node2;
local idexpression struct iattr *attr1;
local idexpression struct iattr *attr2;
local idexpression struct iattr attr;
identifier i_xtime1 =~ "^i_[acm]time$";
identifier i_xtime2 =~ "^i_[acm]time$";
identifier ia_xtime1 =~ "^ia_[acm]time$";
identifier ia_xtime2 =~ "^ia_[acm]time$";
@@
(
(
- struct timespec ts;
+ struct timespec64 ts;
|
- struct timespec ts = current_time(inode_node);
+ struct timespec64 ts = current_time(inode_node);
)
<+... when != ts
(
- timespec_equal(&inode_node->i_xtime, &ts)
+ timespec64_equal(&inode_node->i_xtime, &ts)
|
- timespec_equal(&ts, &inode_node->i_xtime)
+ timespec64_equal(&ts, &inode_node->i_xtime)
|
- timespec_compare(&inode_node->i_xtime, &ts)
+ timespec64_compare(&inode_node->i_xtime, &ts)
|
- timespec_compare(&ts, &inode_node->i_xtime)
+ timespec64_compare(&ts, &inode_node->i_xtime)
|
ts = current_time(e)
|
fn_update_time(..., &ts,...)
|
inode_node->i_xtime = ts
|
node1->i_xtime = ts
|
ts = inode_node->i_xtime
|
<+... attr1->ia_xtime ...+> = ts
|
ts = attr1->ia_xtime
|
ts.tv_sec
|
ts.tv_nsec
|
btrfs_set_stack_timespec_sec(..., ts.tv_sec)
|
btrfs_set_stack_timespec_nsec(..., ts.tv_nsec)
|
- ts = timespec64_to_timespec(
+ ts =
...
-)
|
- ts = ktime_to_timespec(
+ ts = ktime_to_timespec64(
...)
|
- ts = E3
+ ts = timespec_to_timespec64(E3)
|
- ktime_get_real_ts(&ts)
+ ktime_get_real_ts64(&ts)
|
fn(...,
- ts
+ timespec64_to_timespec(ts)
,...)
)
...+>
(
<... when != ts
- return ts;
+ return timespec64_to_timespec(ts);
...>
)
|
- timespec_equal(&node1->i_xtime1, &node2->i_xtime2)
+ timespec64_equal(&node1->i_xtime2, &node2->i_xtime2)
|
- timespec_equal(&node1->i_xtime1, &attr2->ia_xtime2)
+ timespec64_equal(&node1->i_xtime2, &attr2->ia_xtime2)
|
- timespec_compare(&node1->i_xtime1, &node2->i_xtime2)
+ timespec64_compare(&node1->i_xtime1, &node2->i_xtime2)
|
node1->i_xtime1 =
- timespec_trunc(attr1->ia_xtime1,
+ timespec64_trunc(attr1->ia_xtime1,
...)
|
- attr1->ia_xtime1 = timespec_trunc(attr2->ia_xtime2,
+ attr1->ia_xtime1 = timespec64_trunc(attr2->ia_xtime2,
...)
|
- ktime_get_real_ts(&attr1->ia_xtime1)
+ ktime_get_real_ts64(&attr1->ia_xtime1)
|
- ktime_get_real_ts(&attr.ia_xtime1)
+ ktime_get_real_ts64(&attr.ia_xtime1)
)
@ depends on patch @
struct inode *node;
struct iattr *attr;
identifier fn;
identifier i_xtime =~ "^i_[acm]time$";
identifier ia_xtime =~ "^ia_[acm]time$";
expression e;
@@
(
- fn(node->i_xtime);
+ fn(timespec64_to_timespec(node->i_xtime));
|
fn(...,
- node->i_xtime);
+ timespec64_to_timespec(node->i_xtime));
|
- e = fn(attr->ia_xtime);
+ e = fn(timespec64_to_timespec(attr->ia_xtime));
)
@ depends on patch forall @
struct inode *node;
struct iattr *attr;
identifier i_xtime =~ "^i_[acm]time$";
identifier ia_xtime =~ "^ia_[acm]time$";
identifier fn;
@@
{
+ struct timespec ts;
<+...
(
+ ts = timespec64_to_timespec(node->i_xtime);
fn (...,
- &node->i_xtime,
+ &ts,
...);
|
+ ts = timespec64_to_timespec(attr->ia_xtime);
fn (...,
- &attr->ia_xtime,
+ &ts,
...);
)
...+>
}
@ depends on patch forall @
struct inode *node;
struct iattr *attr;
struct kstat *stat;
identifier ia_xtime =~ "^ia_[acm]time$";
identifier i_xtime =~ "^i_[acm]time$";
identifier xtime =~ "^[acm]time$";
identifier fn, ret;
@@
{
+ struct timespec ts;
<+...
(
+ ts = timespec64_to_timespec(node->i_xtime);
ret = fn (...,
- &node->i_xtime,
+ &ts,
...);
|
+ ts = timespec64_to_timespec(node->i_xtime);
ret = fn (...,
- &node->i_xtime);
+ &ts);
|
+ ts = timespec64_to_timespec(attr->ia_xtime);
ret = fn (...,
- &attr->ia_xtime,
+ &ts,
...);
|
+ ts = timespec64_to_timespec(attr->ia_xtime);
ret = fn (...,
- &attr->ia_xtime);
+ &ts);
|
+ ts = timespec64_to_timespec(stat->xtime);
ret = fn (...,
- &stat->xtime);
+ &ts);
)
...+>
}
@ depends on patch @
struct inode *node;
struct inode *node2;
identifier i_xtime1 =~ "^i_[acm]time$";
identifier i_xtime2 =~ "^i_[acm]time$";
identifier i_xtime3 =~ "^i_[acm]time$";
struct iattr *attrp;
struct iattr *attrp2;
struct iattr attr ;
identifier ia_xtime1 =~ "^ia_[acm]time$";
identifier ia_xtime2 =~ "^ia_[acm]time$";
struct kstat *stat;
struct kstat stat1;
struct timespec64 ts;
identifier xtime =~ "^[acmb]time$";
expression e;
@@
(
( node->i_xtime2 \| attrp->ia_xtime2 \| attr.ia_xtime2 \) = node->i_xtime1 ;
|
node->i_xtime2 = \( node2->i_xtime1 \| timespec64_trunc(...) \);
|
node->i_xtime2 = node->i_xtime1 = node->i_xtime3 = \(ts \| current_time(...) \);
|
node->i_xtime1 = node->i_xtime3 = \(ts \| current_time(...) \);
|
stat->xtime = node2->i_xtime1;
|
stat1.xtime = node2->i_xtime1;
|
( node->i_xtime2 \| attrp->ia_xtime2 \) = attrp->ia_xtime1 ;
|
( attrp->ia_xtime1 \| attr.ia_xtime1 \) = attrp2->ia_xtime2;
|
- e = node->i_xtime1;
+ e = timespec64_to_timespec( node->i_xtime1 );
|
- e = attrp->ia_xtime1;
+ e = timespec64_to_timespec( attrp->ia_xtime1 );
|
node->i_xtime1 = current_time(...);
|
node->i_xtime2 = node->i_xtime1 = node->i_xtime3 =
- e;
+ timespec_to_timespec64(e);
|
node->i_xtime1 = node->i_xtime3 =
- e;
+ timespec_to_timespec64(e);
|
- node->i_xtime1 = e;
+ node->i_xtime1 = timespec_to_timespec64(e);
)
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: <anton@tuxera.com>
Cc: <balbi@kernel.org>
Cc: <bfields@fieldses.org>
Cc: <darrick.wong@oracle.com>
Cc: <dhowells@redhat.com>
Cc: <dsterba@suse.com>
Cc: <dwmw2@infradead.org>
Cc: <hch@lst.de>
Cc: <hirofumi@mail.parknet.co.jp>
Cc: <hubcap@omnibond.com>
Cc: <jack@suse.com>
Cc: <jaegeuk@kernel.org>
Cc: <jaharkes@cs.cmu.edu>
Cc: <jslaby@suse.com>
Cc: <keescook@chromium.org>
Cc: <mark@fasheh.com>
Cc: <miklos@szeredi.hu>
Cc: <nico@linaro.org>
Cc: <reiserfs-devel@vger.kernel.org>
Cc: <richard@nod.at>
Cc: <sage@redhat.com>
Cc: <sfrench@samba.org>
Cc: <swhiteho@redhat.com>
Cc: <tj@kernel.org>
Cc: <trond.myklebust@primarydata.com>
Cc: <tytso@mit.edu>
Cc: <viro@zeniv.linux.org.uk>
2018-05-09 10:36:02 +08:00
|
|
|
struct timespec64 cur_time;
|
2013-03-04 17:44:29 +08:00
|
|
|
int ret = 0;
|
2010-05-16 22:49:58 +08:00
|
|
|
u64 to_reserve = 0;
|
2010-03-16 01:27:13 +08:00
|
|
|
u64 index = 0;
|
2010-05-16 22:48:46 +08:00
|
|
|
u64 objectid;
|
2010-12-20 16:04:08 +08:00
|
|
|
u64 root_flags;
|
2008-01-09 04:46:30 +08:00
|
|
|
|
2015-11-11 01:54:03 +08:00
|
|
|
ASSERT(pending->path);
|
|
|
|
path = pending->path;
|
2012-09-06 18:03:32 +08:00
|
|
|
|
2015-11-11 01:54:00 +08:00
|
|
|
ASSERT(pending->root_item);
|
|
|
|
new_root_item = pending->root_item;
|
2010-05-16 22:48:46 +08:00
|
|
|
|
2013-03-04 17:44:29 +08:00
|
|
|
pending->error = btrfs_find_free_objectid(tree_root, &objectid);
|
|
|
|
if (pending->error)
|
2012-09-06 18:00:32 +08:00
|
|
|
goto no_free_objectid;
|
2008-01-09 04:46:30 +08:00
|
|
|
|
2015-04-20 10:09:06 +08:00
|
|
|
/*
|
|
|
|
* Make qgroup to skip current new snapshot's qgroupid, as it is
|
|
|
|
* accounted by later btrfs_qgroup_inherit().
|
|
|
|
*/
|
|
|
|
btrfs_set_skip_qgroup(trans, objectid);
|
|
|
|
|
2015-08-06 20:58:11 +08:00
|
|
|
btrfs_reloc_pre_snapshot(pending, &to_reserve);
|
2010-05-16 22:49:58 +08:00
|
|
|
|
|
|
|
if (to_reserve > 0) {
|
2013-03-04 17:44:29 +08:00
|
|
|
pending->error = btrfs_block_rsv_add(root,
|
|
|
|
&pending->block_rsv,
|
|
|
|
to_reserve,
|
|
|
|
BTRFS_RESERVE_NO_FLUSH);
|
|
|
|
if (pending->error)
|
2015-04-20 10:09:06 +08:00
|
|
|
goto clear_skip_qgroup;
|
2010-05-16 22:49:58 +08:00
|
|
|
}
|
|
|
|
|
2008-01-09 04:46:30 +08:00
|
|
|
key.objectid = objectid;
|
2010-05-16 22:48:46 +08:00
|
|
|
key.offset = (u64)-1;
|
|
|
|
key.type = BTRFS_ROOT_ITEM_KEY;
|
2008-01-09 04:46:30 +08:00
|
|
|
|
2012-09-06 18:00:32 +08:00
|
|
|
rsv = trans->block_rsv;
|
2010-05-16 22:48:46 +08:00
|
|
|
trans->block_rsv = &pending->block_rsv;
|
2013-02-22 12:33:36 +08:00
|
|
|
trans->bytes_reserved = trans->block_rsv->reserved;
|
2016-06-23 06:54:23 +08:00
|
|
|
trace_btrfs_space_reservation(fs_info, "transaction",
|
2016-01-14 02:21:20 +08:00
|
|
|
trans->transid,
|
|
|
|
trans->bytes_reserved, 1);
|
2010-05-16 22:48:46 +08:00
|
|
|
dentry = pending->dentry;
|
2013-02-28 18:01:15 +08:00
|
|
|
parent_inode = pending->dir;
|
2010-05-16 22:48:46 +08:00
|
|
|
parent_root = BTRFS_I(parent_inode)->root;
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
record_root_in_trans(trans, parent_root, 0);
|
2010-05-16 22:48:46 +08:00
|
|
|
|
2016-09-14 22:48:06 +08:00
|
|
|
cur_time = current_time(parent_inode);
|
2016-02-07 15:57:21 +08:00
|
|
|
|
2008-01-09 04:46:30 +08:00
|
|
|
/*
|
|
|
|
* insert the directory item
|
|
|
|
*/
|
2017-02-20 19:50:33 +08:00
|
|
|
ret = btrfs_set_inode_index(BTRFS_I(parent_inode), &index);
|
2012-03-02 00:24:58 +08:00
|
|
|
BUG_ON(ret); /* -ENOMEM */
|
2012-09-06 18:03:32 +08:00
|
|
|
|
|
|
|
/* check if there is a file/dir which has the same name. */
|
|
|
|
dir_item = btrfs_lookup_dir_item(NULL, parent_root, path,
|
2017-01-11 02:35:31 +08:00
|
|
|
btrfs_ino(BTRFS_I(parent_inode)),
|
2012-09-06 18:03:32 +08:00
|
|
|
dentry->d_name.name,
|
|
|
|
dentry->d_name.len, 0);
|
|
|
|
if (dir_item != NULL && !IS_ERR(dir_item)) {
|
2012-02-20 21:40:56 +08:00
|
|
|
pending->error = -EEXIST;
|
2013-03-04 17:44:29 +08:00
|
|
|
goto dir_item_existed;
|
2012-09-06 18:03:32 +08:00
|
|
|
} else if (IS_ERR(dir_item)) {
|
|
|
|
ret = PTR_ERR(dir_item);
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
2012-03-12 23:03:00 +08:00
|
|
|
}
|
2012-09-06 18:03:32 +08:00
|
|
|
btrfs_release_path(path);
|
2009-01-06 04:43:43 +08:00
|
|
|
|
2011-06-18 04:14:09 +08:00
|
|
|
/*
|
|
|
|
* pull in the delayed directory update
|
|
|
|
* and the delayed inode item
|
|
|
|
* otherwise we corrupt the FS during
|
|
|
|
* snapshot
|
|
|
|
*/
|
2018-02-07 23:55:43 +08:00
|
|
|
ret = btrfs_run_delayed_items(trans);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) { /* Transaction aborted */
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2011-06-18 04:14:09 +08:00
|
|
|
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
record_root_in_trans(trans, root, 0);
|
2010-03-16 01:27:13 +08:00
|
|
|
btrfs_set_root_last_snapshot(&root->root_item, trans->transid);
|
|
|
|
memcpy(new_root_item, &root->root_item, sizeof(*new_root_item));
|
2011-03-28 10:01:25 +08:00
|
|
|
btrfs_check_and_init_root_item(new_root_item);
|
2010-03-16 01:27:13 +08:00
|
|
|
|
2010-12-20 16:04:08 +08:00
|
|
|
root_flags = btrfs_root_flags(new_root_item);
|
|
|
|
if (pending->readonly)
|
|
|
|
root_flags |= BTRFS_ROOT_SUBVOL_RDONLY;
|
|
|
|
else
|
|
|
|
root_flags &= ~BTRFS_ROOT_SUBVOL_RDONLY;
|
|
|
|
btrfs_set_root_flags(new_root_item, root_flags);
|
|
|
|
|
2012-07-25 23:35:53 +08:00
|
|
|
btrfs_set_root_generation_v2(new_root_item,
|
|
|
|
trans->transid);
|
2020-02-24 23:37:51 +08:00
|
|
|
generate_random_guid(new_root_item->uuid);
|
2012-07-25 23:35:53 +08:00
|
|
|
memcpy(new_root_item->parent_uuid, root->root_item.uuid,
|
|
|
|
BTRFS_UUID_SIZE);
|
2013-04-17 17:11:47 +08:00
|
|
|
if (!(root_flags & BTRFS_ROOT_SUBVOL_RDONLY)) {
|
|
|
|
memset(new_root_item->received_uuid, 0,
|
|
|
|
sizeof(new_root_item->received_uuid));
|
|
|
|
memset(&new_root_item->stime, 0, sizeof(new_root_item->stime));
|
|
|
|
memset(&new_root_item->rtime, 0, sizeof(new_root_item->rtime));
|
|
|
|
btrfs_set_root_stransid(new_root_item, 0);
|
|
|
|
btrfs_set_root_rtransid(new_root_item, 0);
|
|
|
|
}
|
2013-07-16 11:19:18 +08:00
|
|
|
btrfs_set_stack_timespec_sec(&new_root_item->otime, cur_time.tv_sec);
|
|
|
|
btrfs_set_stack_timespec_nsec(&new_root_item->otime, cur_time.tv_nsec);
|
2012-07-25 23:35:53 +08:00
|
|
|
btrfs_set_root_otransid(new_root_item, trans->transid);
|
|
|
|
|
2010-03-16 01:27:13 +08:00
|
|
|
old = btrfs_lock_root_node(root);
|
2020-08-20 23:46:03 +08:00
|
|
|
ret = btrfs_cow_block(trans, root, old, NULL, 0, &old,
|
|
|
|
BTRFS_NESTING_COW);
|
2012-03-12 23:03:00 +08:00
|
|
|
if (ret) {
|
|
|
|
btrfs_tree_unlock(old);
|
|
|
|
free_extent_buffer(old);
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
2012-03-12 23:03:00 +08:00
|
|
|
}
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2018-04-04 08:03:48 +08:00
|
|
|
btrfs_set_lock_blocking_write(old);
|
2010-03-16 01:27:13 +08:00
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
ret = btrfs_copy_root(trans, root, old, &tmp, objectid);
|
2012-03-12 23:03:00 +08:00
|
|
|
/* clean up in any case */
|
2010-03-16 01:27:13 +08:00
|
|
|
btrfs_tree_unlock(old);
|
|
|
|
free_extent_buffer(old);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2011-11-15 09:48:06 +08:00
|
|
|
/* see comments in should_cow_block() */
|
2014-04-02 19:51:05 +08:00
|
|
|
set_bit(BTRFS_ROOT_FORCE_COW, &root->state);
|
2011-11-15 09:48:06 +08:00
|
|
|
smp_wmb();
|
|
|
|
|
2010-03-16 01:27:13 +08:00
|
|
|
btrfs_set_root_node(new_root_item, tmp);
|
2010-05-16 22:48:46 +08:00
|
|
|
/* record when the snapshot was created in key.offset */
|
|
|
|
key.offset = trans->transid;
|
|
|
|
ret = btrfs_insert_root(trans, tree_root, &key, new_root_item);
|
2010-03-16 01:27:13 +08:00
|
|
|
btrfs_tree_unlock(tmp);
|
|
|
|
free_extent_buffer(tmp);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2010-03-16 01:27:13 +08:00
|
|
|
|
2010-05-16 22:48:46 +08:00
|
|
|
/*
|
|
|
|
* insert root back/forward references
|
|
|
|
*/
|
2018-08-01 11:32:29 +08:00
|
|
|
ret = btrfs_add_root_ref(trans, objectid,
|
2008-11-18 09:37:39 +08:00
|
|
|
parent_root->root_key.objectid,
|
2017-01-11 02:35:31 +08:00
|
|
|
btrfs_ino(BTRFS_I(parent_inode)), index,
|
2010-05-16 22:48:46 +08:00
|
|
|
dentry->d_name.name, dentry->d_name.len);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2008-11-18 09:37:39 +08:00
|
|
|
|
2010-05-16 22:48:46 +08:00
|
|
|
key.offset = (u64)-1;
|
2020-06-16 10:17:36 +08:00
|
|
|
pending->snap = btrfs_get_new_fs_root(fs_info, objectid, pending->anon_dev);
|
2012-03-12 23:03:00 +08:00
|
|
|
if (IS_ERR(pending->snap)) {
|
|
|
|
ret = PTR_ERR(pending->snap);
|
2020-09-05 00:22:57 +08:00
|
|
|
pending->snap = NULL;
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
2012-03-12 23:03:00 +08:00
|
|
|
}
|
2010-05-16 22:49:58 +08:00
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
ret = btrfs_reloc_post_snapshot(trans, pending);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
Btrfs: fix full backref problem when inserting shared block reference
If we create several snapshots at the same time, the following BUG_ON() will be
triggered.
kernel BUG at fs/btrfs/extent-tree.c:6047!
Steps to reproduce:
# mkfs.btrfs <partition>
# mount <partition> <mnt>
# cd <mnt>
# for ((i=0;i<2400;i++)); do touch long_name_to_make_tree_more_deep$i; done
# for ((i=0; i<4; i++))
> do
> mkdir $i
> for ((j=0; j<200; j++))
> do
> btrfs sub snap . $i/$j
> done &
> done
The reason is:
Before transaction commit, some operations changed the fs tree and new tree
blocks were allocated because of COW. We used the implicit non-shared back
reference for those newly allocated tree blocks because they were not shared by
two or more trees.
And then we created the first snapshot for the fs tree, according to the back
reference rules, we also used implicit back refs for the child tree blocks of
the root node of the fs tree, now those child nodes/leaves were shared by two
trees.
Then We didn't deal with the delayed references, and continued to change the fs
tree(created the second snapshot and inserted the dir item of the new snapshot
into the fs tree). According to the rules of the back reference, we added full
back refs for those tree blocks whose parents have be shared by two trees.
Now some newly allocated tree blocks had two types of the references.
As we know, the delayed reference system handles these delayed references from
back to front, and the full delayed reference is inserted after the implicit
ones. So when we dealt with the back references of those newly allocated tree
blocks, the full references was dealt with at first. And if the first reference
is a shared back reference and the tree block that the reference points to is
newly allocated, It would be considered as a tree block which is shared by two
or more trees when it is allocated and should be a full back reference not a
implicit one, the flag of its reference also should be set to FULL_BACKREF.
But in fact, it was a non-shared tree block with a implicit reference at
beginning, so it was not compulsory to set the flags to FULL_BACKREF. So BUG_ON
was triggered.
We have several methods to fix this bug:
1. deal with delayed references after the snapshot is created and before we
change the source tree of the snapshot. This is the easiest and safest way.
2. modify the sort method of the delayed reference tree, make the full delayed
references be inserted before the implicit ones. It is also very easy, but
I don't know if it will introduce some problems or not.
3. modify select_delayed_ref() and make it select the implicit delayed reference
at first. This way is not so good because it may wastes CPU time if we have
lots of delayed references.
4. set the flags to FULL_BACKREF, this method is a little complex comparing with
the 1st way.
I chose the 1st way to fix it.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
2012-09-06 18:00:57 +08:00
|
|
|
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2012-09-06 18:03:32 +08:00
|
|
|
|
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
inside btrfs_commit_transaction() just be commit_cowonly_roots().
However there is a exception at create_pending_snapshot(), which will
call btrfs_qgroup_account_extents() but no any commit root switch.
In case of creating a snapshot whose parent root is itself (create a
snapshot of fs tree), it will corrupt qgroup by the following trace:
(skipped unrelated data)
======
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 1
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 0, excl = 0
qgroup_update_counters: qgid = 5, cur_old_count = 0, cur_new_count = 1, rfer = 16384, excl = 16384
btrfs_qgroup_account_extent: bytenr = 29786112, num_bytes = 16384, nr_old_roots = 0, nr_new_roots = 0
======
The problem here is in first qgroup_account_extent(), the
nr_new_roots of the extent is 1, which means its reference got
increased, and qgroup increased its rfer and excl.
But at second qgroup_account_extent(), its reference got decreased, but
between these two qgroup_account_extent(), there is no switch roots.
This leads to the same nr_old_roots, and this extent just got ignored by
qgroup, which means this extent is wrongly accounted.
Fix it by call commit_cowonly_roots() after qgroup_account_extent() in
create_pending_snapshot(), with needed preparation.
Mark: I added a check at the top of qgroup_account_snapshot() to skip this
code if qgroups are turned off. xfstest btrfs/122 exposes this problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
2016-05-12 03:53:52 +08:00
|
|
|
/*
|
|
|
|
* Do special qgroup accounting for snapshot, as we do some qgroup
|
|
|
|
* snapshot hack to do fast snapshot.
|
|
|
|
* To co-operate with that hack, we do hack again.
|
|
|
|
* Or snapshot will be greatly slowed down by a subtree qgroup rescan
|
|
|
|
*/
|
|
|
|
ret = qgroup_account_snapshot(trans, root, parent_root,
|
|
|
|
pending->inherit, objectid);
|
|
|
|
if (ret < 0)
|
|
|
|
goto fail;
|
|
|
|
|
2018-08-04 21:10:57 +08:00
|
|
|
ret = btrfs_insert_dir_item(trans, dentry->d_name.name,
|
|
|
|
dentry->d_name.len, BTRFS_I(parent_inode),
|
|
|
|
&key, BTRFS_FT_DIR, index);
|
2012-09-06 18:03:32 +08:00
|
|
|
/* We have check then name at the beginning, so it is impossible. */
|
2012-12-18 03:26:57 +08:00
|
|
|
BUG_ON(ret == -EEXIST || ret == -EOVERFLOW);
|
2012-09-18 13:52:38 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2012-09-18 13:52:38 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2012-09-06 18:03:32 +08:00
|
|
|
|
2017-02-20 19:50:34 +08:00
|
|
|
btrfs_i_size_write(BTRFS_I(parent_inode), parent_inode->i_size +
|
2012-09-06 18:03:32 +08:00
|
|
|
dentry->d_name.len * 2);
|
2016-02-07 15:57:21 +08:00
|
|
|
parent_inode->i_mtime = parent_inode->i_ctime =
|
2016-09-14 22:48:06 +08:00
|
|
|
current_time(parent_inode);
|
2012-10-23 03:43:12 +08:00
|
|
|
ret = btrfs_update_inode_fallback(trans, parent_root, parent_inode);
|
2013-08-15 23:11:20 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2013-08-15 23:11:20 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2020-02-24 23:37:51 +08:00
|
|
|
ret = btrfs_uuid_tree_add(trans, new_root_item->uuid,
|
|
|
|
BTRFS_UUID_KEY_SUBVOL,
|
2018-05-29 15:01:53 +08:00
|
|
|
objectid);
|
2013-08-15 23:11:20 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2013-08-15 23:11:20 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
if (!btrfs_is_empty_uuid(new_root_item->received_uuid)) {
|
2018-05-29 15:01:53 +08:00
|
|
|
ret = btrfs_uuid_tree_add(trans, new_root_item->received_uuid,
|
2013-08-15 23:11:20 +08:00
|
|
|
BTRFS_UUID_KEY_RECEIVED_SUBVOL,
|
|
|
|
objectid);
|
|
|
|
if (ret && ret != -EEXIST) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2013-08-15 23:11:20 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
2015-04-20 10:09:06 +08:00
|
|
|
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2015-04-20 10:09:06 +08:00
|
|
|
if (ret) {
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, ret);
|
2015-04-20 10:09:06 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2008-01-09 04:46:30 +08:00
|
|
|
fail:
|
2013-03-04 17:44:29 +08:00
|
|
|
pending->error = ret;
|
|
|
|
dir_item_existed:
|
2011-09-11 22:52:24 +08:00
|
|
|
trans->block_rsv = rsv;
|
2013-02-22 12:33:36 +08:00
|
|
|
trans->bytes_reserved = 0;
|
2015-04-20 10:09:06 +08:00
|
|
|
clear_skip_qgroup:
|
|
|
|
btrfs_clear_skip_qgroup(trans);
|
2012-09-06 18:00:32 +08:00
|
|
|
no_free_objectid:
|
|
|
|
kfree(new_root_item);
|
2015-11-11 01:54:00 +08:00
|
|
|
pending->root_item = NULL;
|
2012-09-06 18:03:32 +08:00
|
|
|
btrfs_free_path(path);
|
2015-11-11 01:54:03 +08:00
|
|
|
pending->path = NULL;
|
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
return ret;
|
2008-01-09 04:46:30 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
|
|
|
* create all the snapshots we've scheduled for creation
|
|
|
|
*/
|
2018-02-07 23:55:48 +08:00
|
|
|
static noinline int create_pending_snapshots(struct btrfs_trans_handle *trans)
|
2008-11-18 10:02:50 +08:00
|
|
|
{
|
2013-03-04 17:44:29 +08:00
|
|
|
struct btrfs_pending_snapshot *pending, *next;
|
2008-11-18 10:02:50 +08:00
|
|
|
struct list_head *head = &trans->transaction->pending_snapshots;
|
2013-03-04 17:44:29 +08:00
|
|
|
int ret = 0;
|
2008-11-18 10:02:50 +08:00
|
|
|
|
2013-03-04 17:44:29 +08:00
|
|
|
list_for_each_entry_safe(pending, next, head, list) {
|
|
|
|
list_del(&pending->list);
|
2018-02-07 23:55:48 +08:00
|
|
|
ret = create_pending_snapshot(trans, pending);
|
2013-03-04 17:44:29 +08:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ret;
|
2008-11-18 10:02:50 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
static void update_super_roots(struct btrfs_fs_info *fs_info)
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
{
|
|
|
|
struct btrfs_root_item *root_item;
|
|
|
|
struct btrfs_super_block *super;
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
super = fs_info->super_copy;
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
root_item = &fs_info->chunk_root->root_item;
|
2018-03-16 21:31:43 +08:00
|
|
|
super->chunk_root = root_item->bytenr;
|
|
|
|
super->chunk_root_generation = root_item->generation;
|
|
|
|
super->chunk_root_level = root_item->level;
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
root_item = &fs_info->tree_root->root_item;
|
2018-03-16 21:31:43 +08:00
|
|
|
super->root = root_item->bytenr;
|
|
|
|
super->generation = root_item->generation;
|
|
|
|
super->root_level = root_item->level;
|
2016-06-23 06:54:23 +08:00
|
|
|
if (btrfs_test_opt(fs_info, SPACE_CACHE))
|
2018-03-16 21:31:43 +08:00
|
|
|
super->cache_generation = root_item->generation;
|
2016-06-23 06:54:23 +08:00
|
|
|
if (test_bit(BTRFS_FS_UPDATE_UUID_TREE_GEN, &fs_info->flags))
|
2018-03-16 21:31:43 +08:00
|
|
|
super->uuid_tree_generation = root_item->generation;
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
}
|
|
|
|
|
2009-07-30 22:04:48 +08:00
|
|
|
int btrfs_transaction_in_commit(struct btrfs_fs_info *info)
|
|
|
|
{
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
struct btrfs_transaction *trans;
|
2009-07-30 22:04:48 +08:00
|
|
|
int ret = 0;
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock(&info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
trans = info->running_transaction;
|
|
|
|
if (trans)
|
|
|
|
ret = (trans->state >= TRANS_STATE_COMMIT_START);
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_unlock(&info->trans_lock);
|
2009-07-30 22:04:48 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-05-16 22:49:58 +08:00
|
|
|
int btrfs_transaction_blocked(struct btrfs_fs_info *info)
|
|
|
|
{
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
struct btrfs_transaction *trans;
|
2010-05-16 22:49:58 +08:00
|
|
|
int ret = 0;
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock(&info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
trans = info->running_transaction;
|
|
|
|
if (trans)
|
|
|
|
ret = is_transaction_blocked(trans);
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_unlock(&info->trans_lock);
|
2010-05-16 22:49:58 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-10-30 03:37:34 +08:00
|
|
|
/*
|
|
|
|
* wait for the current transaction commit to start and block subsequent
|
|
|
|
* transaction joins
|
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
static void wait_current_trans_commit_start(struct btrfs_fs_info *fs_info,
|
2010-10-30 03:37:34 +08:00
|
|
|
struct btrfs_transaction *trans)
|
|
|
|
{
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_event(fs_info->transaction_blocked_wait,
|
2020-02-06 00:34:34 +08:00
|
|
|
trans->state >= TRANS_STATE_COMMIT_START ||
|
|
|
|
TRANS_ABORTED(trans));
|
2010-10-30 03:37:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* wait for the current transaction to start and then become unblocked.
|
|
|
|
* caller holds ref.
|
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
static void wait_current_trans_commit_start_and_unblock(
|
|
|
|
struct btrfs_fs_info *fs_info,
|
|
|
|
struct btrfs_transaction *trans)
|
2010-10-30 03:37:34 +08:00
|
|
|
{
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_event(fs_info->transaction_wait,
|
2020-02-06 00:34:34 +08:00
|
|
|
trans->state >= TRANS_STATE_UNBLOCKED ||
|
|
|
|
TRANS_ABORTED(trans));
|
2010-10-30 03:37:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* commit transactions asynchronously. once btrfs_commit_transaction_async
|
|
|
|
* returns, any subsequent transaction will not be allowed to join.
|
|
|
|
*/
|
|
|
|
struct btrfs_async_commit {
|
|
|
|
struct btrfs_trans_handle *newtrans;
|
2012-11-15 16:14:47 +08:00
|
|
|
struct work_struct work;
|
2010-10-30 03:37:34 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static void do_async_commit(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct btrfs_async_commit *ac =
|
2012-11-15 16:14:47 +08:00
|
|
|
container_of(work, struct btrfs_async_commit, work);
|
2010-10-30 03:37:34 +08:00
|
|
|
|
2012-08-31 06:26:15 +08:00
|
|
|
/*
|
|
|
|
* We've got freeze protection passed with the transaction.
|
|
|
|
* Tell lockdep about it.
|
|
|
|
*/
|
2013-11-06 16:57:55 +08:00
|
|
|
if (ac->newtrans->type & __TRANS_FREEZABLE)
|
2016-09-10 09:39:03 +08:00
|
|
|
__sb_writers_acquired(ac->newtrans->fs_info->sb, SB_FREEZE_FS);
|
2012-08-31 06:26:15 +08:00
|
|
|
|
2012-08-31 06:26:16 +08:00
|
|
|
current->journal_info = ac->newtrans;
|
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_commit_transaction(ac->newtrans);
|
2010-10-30 03:37:34 +08:00
|
|
|
kfree(ac);
|
|
|
|
}
|
|
|
|
|
|
|
|
int btrfs_commit_transaction_async(struct btrfs_trans_handle *trans,
|
|
|
|
int wait_for_unblock)
|
|
|
|
{
|
2016-09-10 09:39:03 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2010-10-30 03:37:34 +08:00
|
|
|
struct btrfs_async_commit *ac;
|
|
|
|
struct btrfs_transaction *cur_trans;
|
|
|
|
|
|
|
|
ac = kmalloc(sizeof(*ac), GFP_NOFS);
|
2011-03-23 16:14:16 +08:00
|
|
|
if (!ac)
|
|
|
|
return -ENOMEM;
|
2010-10-30 03:37:34 +08:00
|
|
|
|
2012-11-15 16:14:47 +08:00
|
|
|
INIT_WORK(&ac->work, do_async_commit);
|
2016-09-10 09:39:03 +08:00
|
|
|
ac->newtrans = btrfs_join_transaction(trans->root);
|
2011-01-25 10:51:38 +08:00
|
|
|
if (IS_ERR(ac->newtrans)) {
|
|
|
|
int err = PTR_ERR(ac->newtrans);
|
|
|
|
kfree(ac);
|
|
|
|
return err;
|
|
|
|
}
|
2010-10-30 03:37:34 +08:00
|
|
|
|
|
|
|
/* take transaction reference */
|
|
|
|
cur_trans = trans->transaction;
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
2010-10-30 03:37:34 +08:00
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_end_transaction(trans);
|
2012-08-31 06:26:15 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Tell lockdep we've released the freeze rwsem, since the
|
|
|
|
* async commit thread will be the one to unlock it.
|
|
|
|
*/
|
2013-11-06 16:57:55 +08:00
|
|
|
if (ac->newtrans->type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
__sb_writers_release(fs_info->sb, SB_FREEZE_FS);
|
2012-08-31 06:26:15 +08:00
|
|
|
|
2012-11-15 16:14:47 +08:00
|
|
|
schedule_work(&ac->work);
|
2010-10-30 03:37:34 +08:00
|
|
|
|
|
|
|
/* wait for transaction to start and unblock */
|
|
|
|
if (wait_for_unblock)
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_current_trans_commit_start_and_unblock(fs_info, cur_trans);
|
2010-10-30 03:37:34 +08:00
|
|
|
else
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_current_trans_commit_start(fs_info, cur_trans);
|
2010-10-30 03:37:34 +08:00
|
|
|
|
2011-06-11 02:43:13 +08:00
|
|
|
if (current->journal_info == trans)
|
|
|
|
current->journal_info = NULL;
|
|
|
|
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
2010-10-30 03:37:34 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2018-02-07 23:55:46 +08:00
|
|
|
static void cleanup_transaction(struct btrfs_trans_handle *trans, int err)
|
2012-03-02 00:24:58 +08:00
|
|
|
{
|
2018-02-07 23:55:46 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2012-03-02 00:24:58 +08:00
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
|
|
|
|
2017-11-08 08:39:58 +08:00
|
|
|
WARN_ON(refcount_read(&trans->use_count) > 1);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2016-06-11 06:19:25 +08:00
|
|
|
btrfs_abort_transaction(trans, err);
|
2012-06-01 03:52:43 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
2013-03-05 00:25:41 +08:00
|
|
|
|
2013-05-15 15:48:26 +08:00
|
|
|
/*
|
|
|
|
* If the transaction is removed from the list, it means this
|
|
|
|
* transaction has been committed successfully, so it is impossible
|
|
|
|
* to call the cleanup function.
|
|
|
|
*/
|
|
|
|
BUG_ON(list_empty(&cur_trans->list));
|
2013-03-05 00:25:41 +08:00
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
list_del_init(&cur_trans->list);
|
2016-06-23 06:54:23 +08:00
|
|
|
if (cur_trans == fs_info->running_transaction) {
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->state = TRANS_STATE_COMMIT_DOING;
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2013-02-27 21:28:25 +08:00
|
|
|
wait_event(cur_trans->writer_wait,
|
|
|
|
atomic_read(&cur_trans->num_writers) == 1);
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
2012-06-01 03:49:57 +08:00
|
|
|
}
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_cleanup_one_transaction(trans->transaction, fs_info);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
|
|
|
if (cur_trans == fs_info->running_transaction)
|
|
|
|
fs_info->running_transaction = NULL;
|
|
|
|
spin_unlock(&fs_info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
|
2013-09-21 10:26:29 +08:00
|
|
|
if (trans->type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
sb_end_intwrite(fs_info->sb);
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
|
|
|
btrfs_put_transaction(cur_trans);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2018-02-07 23:55:46 +08:00
|
|
|
trace_btrfs_transaction_commit(trans->root);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
|
|
|
if (current->journal_info == trans)
|
|
|
|
current->journal_info = NULL;
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_scrub_cancel(fs_info);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
|
|
|
kmem_cache_free(btrfs_trans_handle_cachep, trans);
|
|
|
|
}
|
|
|
|
|
2019-01-24 00:09:16 +08:00
|
|
|
/*
|
|
|
|
* Release reserved delayed ref space of all pending block groups of the
|
|
|
|
* transaction and remove them from the list
|
|
|
|
*/
|
|
|
|
static void btrfs_cleanup_pending_block_groups(struct btrfs_trans_handle *trans)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2019-10-30 02:20:18 +08:00
|
|
|
struct btrfs_block_group *block_group, *tmp;
|
2019-01-24 00:09:16 +08:00
|
|
|
|
|
|
|
list_for_each_entry_safe(block_group, tmp, &trans->new_bgs, bg_list) {
|
|
|
|
btrfs_delayed_refs_rsv_release(fs_info, 1);
|
|
|
|
list_del_init(&block_group->bg_list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
static inline int btrfs_start_delalloc_flush(struct btrfs_trans_handle *trans)
|
2013-05-15 15:48:28 +08:00
|
|
|
{
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
|
|
|
|
2017-10-20 02:16:01 +08:00
|
|
|
/*
|
|
|
|
* We use writeback_inodes_sb here because if we used
|
|
|
|
* btrfs_start_delalloc_roots we would deadlock with fs freeze.
|
|
|
|
* Currently are holding the fs freeze lock, if we do an async flush
|
|
|
|
* we'll do btrfs_join_transaction() and deadlock because we need to
|
|
|
|
* wait for the fs freeze lock. Using the direct flushing we benefit
|
|
|
|
* from already being in a transaction and our join_transaction doesn't
|
|
|
|
* have to re-take the fs freeze lock.
|
|
|
|
*/
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
if (btrfs_test_opt(fs_info, FLUSHONCOMMIT)) {
|
2017-10-20 02:16:01 +08:00
|
|
|
writeback_inodes_sb(fs_info->sb, WB_REASON_SYNC);
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
} else {
|
|
|
|
struct btrfs_pending_snapshot *pending;
|
|
|
|
struct list_head *head = &trans->transaction->pending_snapshots;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flush dellaloc for any root that is going to be snapshotted.
|
|
|
|
* This is done to avoid a corrupted version of files, in the
|
|
|
|
* snapshots, that had both buffered and direct IO writes (even
|
|
|
|
* if they were done sequentially) due to an unordered update of
|
|
|
|
* the inode's size on disk.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(pending, head, list) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = btrfs_start_delalloc_snapshot(pending->root);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2013-05-15 15:48:28 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
static inline void btrfs_wait_delalloc_flush(struct btrfs_trans_handle *trans)
|
2013-05-15 15:48:28 +08:00
|
|
|
{
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
|
|
|
|
|
|
|
if (btrfs_test_opt(fs_info, FLUSHONCOMMIT)) {
|
2017-06-24 00:48:21 +08:00
|
|
|
btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1);
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
} else {
|
|
|
|
struct btrfs_pending_snapshot *pending;
|
|
|
|
struct list_head *head = &trans->transaction->pending_snapshots;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for any dellaloc that we started previously for the roots
|
|
|
|
* that are going to be snapshotted. This is to avoid a corrupted
|
|
|
|
* version of files in the snapshots that had both buffered and
|
|
|
|
* direct IO writes (even if they were done sequentially).
|
|
|
|
*/
|
|
|
|
list_for_each_entry(pending, head, list)
|
|
|
|
btrfs_wait_ordered_extents(pending->root,
|
|
|
|
U64_MAX, 0, U64_MAX);
|
|
|
|
}
|
2013-05-15 15:48:28 +08:00
|
|
|
}
|
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
int btrfs_commit_transaction(struct btrfs_trans_handle *trans)
|
2007-03-23 03:59:16 +08:00
|
|
|
{
|
2016-09-10 09:39:03 +08:00
|
|
|
struct btrfs_fs_info *fs_info = trans->fs_info;
|
2012-03-02 00:24:58 +08:00
|
|
|
struct btrfs_transaction *cur_trans = trans->transaction;
|
2007-04-20 09:01:03 +08:00
|
|
|
struct btrfs_transaction *prev_trans = NULL;
|
2012-10-25 17:31:03 +08:00
|
|
|
int ret;
|
2007-03-23 03:59:16 +08:00
|
|
|
|
2019-09-12 23:31:44 +08:00
|
|
|
ASSERT(refcount_read(&trans->use_count) == 1);
|
|
|
|
|
2020-01-17 21:57:51 +08:00
|
|
|
/*
|
|
|
|
* Some places just start a transaction to commit it. We need to make
|
|
|
|
* sure that if this commit fails that the abort code actually marks the
|
|
|
|
* transaction as failed, so set trans->dirty to make the abort code do
|
|
|
|
* the right thing.
|
|
|
|
*/
|
|
|
|
trans->dirty = true;
|
|
|
|
|
2013-01-15 14:27:25 +08:00
|
|
|
/* Stop the commit early if ->aborted is set */
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(cur_trans)) {
|
2012-10-25 17:31:03 +08:00
|
|
|
ret = cur_trans->aborted;
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_end_transaction(trans);
|
2013-02-07 05:55:41 +08:00
|
|
|
return ret;
|
2012-10-25 17:31:03 +08:00
|
|
|
}
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2018-09-28 19:17:48 +08:00
|
|
|
btrfs_trans_release_metadata(trans);
|
|
|
|
trans->block_rsv = NULL;
|
|
|
|
|
2009-03-13 22:10:06 +08:00
|
|
|
/* make a pass through all the delayed refs we have so far
|
|
|
|
* any runnings procs may add more while we are here
|
|
|
|
*/
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, 0);
|
2013-02-07 05:55:41 +08:00
|
|
|
if (ret) {
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_end_transaction(trans);
|
2013-02-07 05:55:41 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2009-03-13 08:12:45 +08:00
|
|
|
cur_trans = trans->transaction;
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2009-03-13 22:10:06 +08:00
|
|
|
/*
|
|
|
|
* set the flushing flag so procs in this transaction have to
|
|
|
|
* start sending their work down.
|
|
|
|
*/
|
2009-03-13 08:12:45 +08:00
|
|
|
cur_trans->delayed_refs.flushing = 1;
|
2013-06-13 01:56:06 +08:00
|
|
|
smp_wmb();
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2018-11-22 03:05:42 +08:00
|
|
|
btrfs_create_pending_block_groups(trans);
|
2012-09-12 04:57:25 +08:00
|
|
|
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, 0);
|
2013-02-07 05:55:41 +08:00
|
|
|
if (ret) {
|
2016-09-10 09:39:03 +08:00
|
|
|
btrfs_end_transaction(trans);
|
2013-02-07 05:55:41 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2015-09-24 22:46:10 +08:00
|
|
|
if (!test_bit(BTRFS_TRANS_DIRTY_BG_RUN, &cur_trans->flags)) {
|
2015-04-07 03:46:08 +08:00
|
|
|
int run_it = 0;
|
|
|
|
|
|
|
|
/* this mutex is also taken before trying to set
|
|
|
|
* block groups readonly. We need to make sure
|
|
|
|
* that nobody has set a block group readonly
|
|
|
|
* after a extents from that block group have been
|
|
|
|
* allocated for cache files. btrfs_set_block_group_ro
|
|
|
|
* will wait for the transaction to commit if it
|
2015-09-24 22:46:10 +08:00
|
|
|
* finds BTRFS_TRANS_DIRTY_BG_RUN set.
|
2015-04-07 03:46:08 +08:00
|
|
|
*
|
2015-09-24 22:46:10 +08:00
|
|
|
* The BTRFS_TRANS_DIRTY_BG_RUN flag is also used to make sure
|
|
|
|
* only one process starts all the block group IO. It wouldn't
|
2015-04-07 03:46:08 +08:00
|
|
|
* hurt to have more than one go through, but there's no
|
|
|
|
* real advantage to it either.
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_lock(&fs_info->ro_block_group_mutex);
|
2015-09-24 22:46:10 +08:00
|
|
|
if (!test_and_set_bit(BTRFS_TRANS_DIRTY_BG_RUN,
|
|
|
|
&cur_trans->flags))
|
2015-04-07 03:46:08 +08:00
|
|
|
run_it = 1;
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_unlock(&fs_info->ro_block_group_mutex);
|
2015-04-07 03:46:08 +08:00
|
|
|
|
2018-02-09 17:30:18 +08:00
|
|
|
if (run_it) {
|
2018-02-07 23:55:41 +08:00
|
|
|
ret = btrfs_start_dirty_block_groups(trans);
|
2018-02-09 17:30:18 +08:00
|
|
|
if (ret) {
|
|
|
|
btrfs_end_transaction(trans);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2015-04-07 03:46:08 +08:00
|
|
|
}
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
if (cur_trans->state >= TRANS_STATE_COMMIT_START) {
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&cur_trans->use_count);
|
2016-09-10 09:39:03 +08:00
|
|
|
ret = btrfs_end_transaction(trans);
|
2007-06-29 03:57:36 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_for_commit(cur_trans);
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(cur_trans))
|
2015-03-06 20:23:44 +08:00
|
|
|
ret = cur_trans->aborted;
|
|
|
|
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2012-03-02 00:24:58 +08:00
|
|
|
return ret;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
2008-01-03 22:08:48 +08:00
|
|
|
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->state = TRANS_STATE_COMMIT_START;
|
2016-06-23 06:54:23 +08:00
|
|
|
wake_up(&fs_info->transaction_blocked_wait);
|
2010-10-30 03:37:34 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
if (cur_trans->list.prev != &fs_info->trans_list) {
|
2007-06-29 03:57:36 +08:00
|
|
|
prev_trans = list_entry(cur_trans->list.prev,
|
|
|
|
struct btrfs_transaction, list);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
if (prev_trans->state != TRANS_STATE_COMPLETED) {
|
2017-03-03 16:55:11 +08:00
|
|
|
refcount_inc(&prev_trans->use_count);
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2007-06-29 03:57:36 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
wait_for_commit(prev_trans);
|
2020-02-06 00:34:34 +08:00
|
|
|
ret = READ_ONCE(prev_trans->aborted);
|
2007-06-29 03:57:36 +08:00
|
|
|
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(prev_trans);
|
Btrfs: check if previous transaction aborted to avoid fs corruption
While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
aborted after we waited for it to commit, so we ended up committing the
current transaction which can lead to fs corruption because the new
superblock can point to trees that have had one or more nodes/leafs that
were never durably persisted.
The following sequence diagram exemplifies how this is possible:
CPU 0 CPU 1
transaction N starts
(...)
btrfs_commit_transaction(N)
cur_trans->state = TRANS_STATE_COMMIT_START;
(...)
cur_trans->state = TRANS_STATE_COMMIT_DOING;
(...)
cur_trans->state = TRANS_STATE_UNBLOCKED;
root->fs_info->running_transaction = NULL;
btrfs_start_transaction()
--> starts transaction N + 1
btrfs_write_and_wait_transaction(trans, root);
--> starts writing all new or COWed ebs created
at transaction N
creates some new ebs, COWs some
existing ebs but doesn't COW or
deletes eb X
btrfs_commit_transaction(N + 1)
(...)
cur_trans->state = TRANS_STATE_COMMIT_START;
(...)
wait_for_commit(root, prev_trans);
--> prev_trans == transaction N
btrfs_write_and_wait_transaction() continues
writing ebs
--> fails writing eb X, we abort transaction N
and set bit BTRFS_FS_STATE_ERROR on
fs_info->fs_state, so no new transactions
can start after setting that bit
cleanup_transaction()
btrfs_cleanup_one_transaction()
wakes up task at CPU 1
continues, doesn't abort because
cur_trans->aborted (transaction N + 1)
is zero, and no checks for bit
BTRFS_FS_STATE_ERROR in fs_info->fs_state
are made
btrfs_write_and_wait_transaction(trans, root);
--> succeeds, no errors during writeback
write_ctree_super(trans, root, 0);
--> succeeds
--> we have now a superblock that points us
to some root that uses eb X, which was
never written to disk
In this scenario future attempts to read eb X from disk results in an
error message like "parent transid verify failed on X wanted Y found Z".
So fix this by aborting the current transaction if after waiting for the
previous transaction we verify that it was aborted.
Cc: stable@vger.kernel.org
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
2015-08-12 18:54:35 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_transaction;
|
2011-04-12 05:25:13 +08:00
|
|
|
} else {
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2007-06-29 03:57:36 +08:00
|
|
|
}
|
2011-04-12 05:25:13 +08:00
|
|
|
} else {
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
Btrfs: fix race leading to fs corruption after transaction abort
When one transaction is finishing its commit, it is possible for another
transaction to start and enter its initial commit phase as well. If the
first ends up getting aborted, we have a small time window where the second
transaction commit does not notice that the previous transaction aborted
and ends up committing, writing a superblock that points to btrees that
reference extent buffers (nodes and leafs) that were not persisted to disk.
The consequence is that after mounting the filesystem again, we will be
unable to load some btree nodes/leafs, either because the content on disk
is either garbage (or just zeroes) or corresponds to the old content of a
previouly COWed or deleted node/leaf, resulting in the well known error
messages "parent transid verify failed on ...".
The following sequence diagram illustrates how this can happen.
CPU 1 CPU 2
<at transaction N>
btrfs_commit_transaction()
(...)
--> sets transaction state to
TRANS_STATE_UNBLOCKED
--> sets fs_info->running_transaction
to NULL
(...)
btrfs_start_transaction()
start_transaction()
wait_current_trans()
--> returns immediately
because
fs_info->running_transaction
is NULL
join_transaction()
--> creates transaction N + 1
--> sets
fs_info->running_transaction
to transaction N + 1
--> adds transaction N + 1 to
the fs_info->trans_list list
--> returns transaction handle
pointing to the new
transaction N + 1
(...)
btrfs_sync_file()
btrfs_start_transaction()
--> returns handle to
transaction N + 1
(...)
btrfs_write_and_wait_transaction()
--> writeback of some extent
buffer fails, returns an
error
btrfs_handle_fs_error()
--> sets BTRFS_FS_STATE_ERROR in
fs_info->fs_state
--> jumps to label "scrub_continue"
cleanup_transaction()
btrfs_abort_transaction(N)
--> sets BTRFS_FS_STATE_TRANS_ABORTED
flag in fs_info->fs_state
--> sets aborted field in the
transaction and transaction
handle structures, for
transaction N only
--> removes transaction from the
list fs_info->trans_list
btrfs_commit_transaction(N + 1)
--> transaction N + 1 was not
aborted, so it proceeds
(...)
--> sets the transaction's state
to TRANS_STATE_COMMIT_START
--> does not find the previous
transaction (N) in the
fs_info->trans_list, so it
doesn't know that transaction
was aborted, and the commit
of transaction N + 1 proceeds
(...)
--> sets transaction N + 1 state
to TRANS_STATE_UNBLOCKED
btrfs_write_and_wait_transaction()
--> succeeds writing all extent
buffers created in the
transaction N + 1
write_all_supers()
--> succeeds
--> we now have a superblock on
disk that points to trees
that refer to at least one
extent buffer that was
never persisted
So fix this by updating the transaction commit path to check if the flag
BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting
the transaction to the TRANS_STATE_COMMIT_START we do not find any previous
transaction in the fs_info->trans_list. If the flag is set, just fail the
transaction commit with -EROFS, as we do in other places. The exact error
code for the previous transaction abort was already logged and reported.
Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-25 18:27:04 +08:00
|
|
|
/*
|
|
|
|
* The previous transaction was aborted and was already removed
|
|
|
|
* from the list of transactions at fs_info->trans_list. So we
|
|
|
|
* abort to prevent writing a new superblock that reflects a
|
|
|
|
* corrupt state (pointing to trees with unwritten nodes/leafs).
|
|
|
|
*/
|
|
|
|
if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) {
|
|
|
|
ret = -EROFS;
|
|
|
|
goto cleanup_transaction;
|
|
|
|
}
|
2007-06-29 03:57:36 +08:00
|
|
|
}
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2013-05-15 15:48:27 +08:00
|
|
|
extwriter_counter_dec(cur_trans, trans->type);
|
|
|
|
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
ret = btrfs_start_delalloc_flush(trans);
|
2013-05-15 15:48:28 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_transaction;
|
|
|
|
|
2018-02-07 23:55:43 +08:00
|
|
|
ret = btrfs_run_delayed_items(trans);
|
2013-05-15 15:48:30 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_transaction;
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2013-05-15 15:48:30 +08:00
|
|
|
wait_event(cur_trans->writer_wait,
|
|
|
|
extwriter_counter_read(cur_trans) == 0);
|
2007-08-11 04:22:09 +08:00
|
|
|
|
2013-05-15 15:48:30 +08:00
|
|
|
/* some pending stuffs might be added after the previous flush. */
|
2018-02-07 23:55:43 +08:00
|
|
|
ret = btrfs_run_delayed_items(trans);
|
2012-11-01 15:33:14 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_transaction;
|
|
|
|
|
Btrfs: fix file corruption after snapshotting due to mix of buffered/DIO writes
When we are mixing buffered writes with direct IO writes against the same
file and snapshotting is happening concurrently, we can end up with a
corrupt file content in the snapshot. Example:
1) Inode/file is empty.
2) Snapshotting starts.
2) Buffered write at offset 0 length 256Kb. This updates the i_size of the
inode to 256Kb, disk_i_size remains zero. This happens after the task
doing the snapshot flushes all existing delalloc.
3) DIO write at offset 256Kb length 768Kb. Once the ordered extent
completes it sets the inode's disk_i_size to 1Mb (256Kb + 768Kb) and
updates the inode item in the fs tree with a size of 1Mb (which is
the value of disk_i_size).
4) The dealloc for the range [0, 256Kb[ did not start yet.
5) The transaction used in the DIO ordered extent completion, which updated
the inode item, is committed by the snapshotting task.
6) Snapshot creation completes.
7) Dealloc for the range [0, 256Kb[ is flushed.
After that when reading the file from the snapshot we always get zeroes for
the range [0, 256Kb[, the file has a size of 1Mb and the data written by
the direct IO write is found. From an application's point of view this is
a corruption, since in the source subvolume it could never read a version
of the file that included the data from the direct IO write without the
data from the buffered write included as well. In the snapshot's tree,
file extent items are missing for the range [0, 256Kb[.
The issue, obviously, does not happen when using the -o flushoncommit
mount option.
Fix this by flushing delalloc for all the roots that are about to be
snapshotted when committing a transaction. This guarantees total ordering
when updating the disk_i_size of an inode since the flush for dealloc is
done when a transaction is in the TRANS_STATE_COMMIT_START state and wait
is done once no more external writers exist. This is similar to what we
do when using the flushoncommit mount option, but we do it only if the
transaction has snapshots to create and only for the roots of the
subvolumes to be snapshotted. The bulk of the dealloc is flushed in the
snapshot creation ioctl, so the flush work we do inside the transaction
is minimized.
This issue, involving buffered and direct IO writes with snapshotting, is
often triggered by fstest btrfs/078, and got reported by fsck when not
using the NO_HOLES features, for example:
$ cat results/btrfs/078.full
(...)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 258 inode 264 errors 100, file extent discount
Found file extent holes:
start: 524288, len: 65536
ERROR: errors found in fs roots
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2019-02-27 21:42:30 +08:00
|
|
|
btrfs_wait_delalloc_flush(trans);
|
2013-12-04 21:16:53 +08: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 19:43:58 +08:00
|
|
|
/*
|
|
|
|
* Wait for all ordered extents started by a fast fsync that joined this
|
|
|
|
* transaction. Otherwise if this transaction commits before the ordered
|
|
|
|
* extents complete we lose logged data after a power failure.
|
|
|
|
*/
|
|
|
|
wait_event(cur_trans->pending_wait,
|
|
|
|
atomic_read(&cur_trans->pending_ordered) == 0);
|
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_scrub_pause(fs_info);
|
2011-06-15 04:22:15 +08:00
|
|
|
/*
|
|
|
|
* Ok now we need to make sure to block out any other joins while we
|
|
|
|
* commit the transaction. We could have started a join before setting
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
* COMMIT_DOING so make sure to wait for num_writers to == 1 again.
|
2011-06-15 04:22:15 +08:00
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->state = TRANS_STATE_COMMIT_DOING;
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2011-06-15 04:22:15 +08:00
|
|
|
wait_event(cur_trans->writer_wait,
|
|
|
|
atomic_read(&cur_trans->num_writers) == 1);
|
|
|
|
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(cur_trans)) {
|
2013-01-15 14:29:12 +08:00
|
|
|
ret = cur_trans->aborted;
|
2014-02-19 19:24:16 +08:00
|
|
|
goto scrub_continue;
|
2013-01-15 14:29:12 +08:00
|
|
|
}
|
2011-06-14 08:00:16 +08:00
|
|
|
/*
|
|
|
|
* the reloc mutex makes sure that we stop
|
|
|
|
* the balancing code from coming in and moving
|
|
|
|
* extents around in the middle of the commit
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_lock(&fs_info->reloc_mutex);
|
2011-06-14 08:00:16 +08:00
|
|
|
|
2012-09-06 18:03:32 +08:00
|
|
|
/*
|
|
|
|
* We needn't worry about the delayed items because we will
|
|
|
|
* deal with them in create_pending_snapshot(), which is the
|
|
|
|
* core function of the snapshot creation.
|
|
|
|
*/
|
2018-02-07 23:55:48 +08:00
|
|
|
ret = create_pending_snapshots(trans);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_reloc;
|
2008-01-09 04:46:30 +08:00
|
|
|
|
2012-09-06 18:03:32 +08:00
|
|
|
/*
|
|
|
|
* We insert the dir indexes of the snapshots and update the inode
|
|
|
|
* of the snapshots' parents after the snapshot creation, so there
|
|
|
|
* are some delayed items which are not dealt with. Now deal with
|
|
|
|
* them.
|
|
|
|
*
|
|
|
|
* We needn't worry that this operation will corrupt the snapshots,
|
|
|
|
* because all the tree which are snapshoted will be forced to COW
|
|
|
|
* the nodes and leaves.
|
|
|
|
*/
|
2018-02-07 23:55:43 +08:00
|
|
|
ret = btrfs_run_delayed_items(trans);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_reloc;
|
btrfs: implement delayed inode items operation
Changelog V5 -> V6:
- Fix oom when the memory load is high, by storing the delayed nodes into the
root's radix tree, and letting btrfs inodes go.
Changelog V4 -> V5:
- Fix the race on adding the delayed node to the inode, which is spotted by
Chris Mason.
- Merge Chris Mason's incremental patch into this patch.
- Fix deadlock between readdir() and memory fault, which is reported by
Itaru Kitayama.
Changelog V3 -> V4:
- Fix nested lock, which is reported by Itaru Kitayama, by updating space cache
inode in time.
Changelog V2 -> V3:
- Fix the race between the delayed worker and the task which does delayed items
balance, which is reported by Tsutomu Itoh.
- Modify the patch address David Sterba's comment.
- Fix the bug of the cpu recursion spinlock, reported by Chris Mason
Changelog V1 -> V2:
- break up the global rb-tree, use a list to manage the delayed nodes,
which is created for every directory and file, and used to manage the
delayed directory name index items and the delayed inode item.
- introduce a worker to deal with the delayed nodes.
Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree insertions,
such as inode item, directory name item, directory name index and so on.
If we can do some delayed b+ tree insertion or deletion, we can improve the
performance, so we made this patch which implemented delayed directory name
index insertion/deletion and delayed inode update.
Implementation:
- introduce a delayed root object into the filesystem, that use two lists to
manage the delayed nodes which are created for every file/directory.
One is used to manage all the delayed nodes that have delayed items. And the
other is used to manage the delayed nodes which is waiting to be dealt with
by the work thread.
- Every delayed node has two rb-tree, one is used to manage the directory name
index which is going to be inserted into b+ tree, and the other is used to
manage the directory name index which is going to be deleted from b+ tree.
- introduce a worker to deal with the delayed operation. This worker is used
to deal with the works of the delayed directory name index items insertion
and deletion and the delayed inode update.
When the delayed items is beyond the lower limit, we create works for some
delayed nodes and insert them into the work queue of the worker, and then
go back.
When the delayed items is beyond the upper bound, we create works for all
the delayed nodes that haven't been dealt with, and insert them into the work
queue of the worker, and then wait for that the untreated items is below some
threshold value.
- When we want to insert a directory name index into b+ tree, we just add the
information into the delayed inserting rb-tree.
And then we check the number of the delayed items and do delayed items
balance. (The balance policy is above.)
- When we want to delete a directory name index from the b+ tree, we search it
in the inserting rb-tree at first. If we look it up, just drop it. If not,
add the key of it into the delayed deleting rb-tree.
Similar to the delayed inserting rb-tree, we also check the number of the
delayed items and do delayed items balance.
(The same to inserting manipulation)
- When we want to update the metadata of some inode, we cached the data of the
inode into the delayed node. the worker will flush it into the b+ tree after
dealing with the delayed insertion and deletion.
- We will move the delayed node to the tail of the list after we access the
delayed node, By this way, we can cache more delayed items and merge more
inode updates.
- If we want to commit transaction, we will deal with all the delayed node.
- the delayed node will be freed when we free the btrfs inode.
- Before we log the inode items, we commit all the directory name index items
and the delayed inode update.
I did a quick test by the benchmark tool[1] and found we can improve the
performance of file creation by ~15%, and file deletion by ~20%.
Before applying this patch:
Create files:
Total files: 50000
Total time: 1.096108
Average time: 0.000022
Delete files:
Total files: 50000
Total time: 1.510403
Average time: 0.000030
After applying this patch:
Create files:
Total files: 50000
Total time: 0.932899
Average time: 0.000019
Delete files:
Total files: 50000
Total time: 1.215732
Average time: 0.000024
[1] http://marc.info/?l=linux-btrfs&m=128212635122920&q=p3
Many thanks for Kitayama-san's help!
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Reviewed-by: David Sterba <dave@jikos.cz>
Tested-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Tested-by: Itaru Kitayama <kitayama@cl.bb4u.ne.jp>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-04-22 18:12:22 +08:00
|
|
|
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_reloc;
|
2009-03-13 22:10:06 +08:00
|
|
|
|
2011-06-18 04:14:09 +08:00
|
|
|
/*
|
|
|
|
* make sure none of the code above managed to slip in a
|
|
|
|
* delayed item
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_assert_delayed_root_empty(fs_info);
|
2011-06-18 04:14:09 +08:00
|
|
|
|
2007-04-02 22:50:19 +08:00
|
|
|
WARN_ON(cur_trans != trans->transaction);
|
2008-01-09 04:46:30 +08:00
|
|
|
|
2008-09-06 04:13:11 +08:00
|
|
|
/* btrfs_commit_tree_roots is responsible for getting the
|
|
|
|
* various roots consistent with each other. Every pointer
|
|
|
|
* in the tree of tree roots has to point to the most up to date
|
|
|
|
* root for every subvolume and other tree. So, we have to keep
|
|
|
|
* the tree logging code from jumping in and changing any
|
|
|
|
* of the trees.
|
|
|
|
*
|
|
|
|
* At this point in the commit, there can't be any tree-log
|
|
|
|
* writers, but a little lower down we drop the trans mutex
|
|
|
|
* and let new people in. By holding the tree_log_mutex
|
|
|
|
* from now until after the super is written, we avoid races
|
|
|
|
* with the tree-log code.
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_lock(&fs_info->tree_log_mutex);
|
2008-09-06 04:13:11 +08:00
|
|
|
|
2018-02-07 23:55:44 +08:00
|
|
|
ret = commit_fs_roots(trans);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_tree_log;
|
2007-06-23 02:16:25 +08:00
|
|
|
|
2014-01-13 13:36:06 +08:00
|
|
|
/*
|
2014-02-05 22:26:17 +08:00
|
|
|
* Since the transaction is done, we can apply the pending changes
|
|
|
|
* before the next transaction.
|
2014-01-13 13:36:06 +08:00
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_apply_pending_changes(fs_info);
|
2014-01-13 13:36:06 +08:00
|
|
|
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
/* commit_fs_roots gets rid of all the tree log roots, it is now
|
2008-09-06 04:13:11 +08:00
|
|
|
* safe to free the root of tree log roots
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_free_log_root_tree(trans, fs_info);
|
2008-09-06 04:13:11 +08:00
|
|
|
|
2017-02-27 15:10:33 +08:00
|
|
|
/*
|
|
|
|
* commit_fs_roots() can call btrfs_save_ino_cache(), which generates
|
|
|
|
* new delayed refs. Must handle them or qgroup can be wrong.
|
|
|
|
*/
|
2018-03-15 23:27:37 +08:00
|
|
|
ret = btrfs_run_delayed_refs(trans, (unsigned long)-1);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_tree_log;
|
2017-02-27 15:10:33 +08:00
|
|
|
|
2015-04-16 16:55:08 +08:00
|
|
|
/*
|
|
|
|
* Since fs roots are all committed, we can get a quite accurate
|
|
|
|
* new_roots. So let's do quota accounting.
|
|
|
|
*/
|
2018-03-15 22:00:25 +08:00
|
|
|
ret = btrfs_qgroup_account_extents(trans);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto unlock_tree_log;
|
2015-04-16 16:55:08 +08:00
|
|
|
|
2018-02-07 23:55:45 +08:00
|
|
|
ret = commit_cowonly_roots(trans);
|
2019-11-28 23:03:00 +08:00
|
|
|
if (ret)
|
|
|
|
goto unlock_tree_log;
|
2007-06-23 02:16:25 +08:00
|
|
|
|
2013-01-15 14:29:12 +08:00
|
|
|
/*
|
|
|
|
* The tasks which save the space cache and inode cache may also
|
|
|
|
* update ->aborted, check it.
|
|
|
|
*/
|
2020-02-06 00:34:34 +08:00
|
|
|
if (TRANS_ABORTED(cur_trans)) {
|
2013-01-15 14:29:12 +08:00
|
|
|
ret = cur_trans->aborted;
|
2019-11-28 23:03:00 +08:00
|
|
|
goto unlock_tree_log;
|
2013-01-15 14:29:12 +08:00
|
|
|
}
|
|
|
|
|
2017-02-11 02:20:56 +08:00
|
|
|
btrfs_prepare_extent_commit(fs_info);
|
2009-09-12 04:11:19 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
cur_trans = fs_info->running_transaction;
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_set_root_node(&fs_info->tree_root->root_item,
|
|
|
|
fs_info->tree_root->node);
|
|
|
|
list_add_tail(&fs_info->tree_root->dirty_list,
|
2014-03-14 03:42:13 +08:00
|
|
|
&cur_trans->switch_commits);
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_set_root_node(&fs_info->chunk_root->root_item,
|
|
|
|
fs_info->chunk_root->node);
|
|
|
|
list_add_tail(&fs_info->chunk_root->dirty_list,
|
2014-03-14 03:42:13 +08:00
|
|
|
&cur_trans->switch_commits);
|
|
|
|
|
2020-01-17 22:12:45 +08:00
|
|
|
switch_commit_roots(trans);
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
|
2014-11-18 04:45:48 +08:00
|
|
|
ASSERT(list_empty(&cur_trans->dirty_bgs));
|
2015-04-07 03:46:08 +08:00
|
|
|
ASSERT(list_empty(&cur_trans->io_bgs));
|
2016-06-23 06:54:24 +08:00
|
|
|
update_super_roots(fs_info);
|
2008-09-06 04:13:11 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_set_super_log_root(fs_info->super_copy, 0);
|
|
|
|
btrfs_set_super_log_root_level(fs_info->super_copy, 0);
|
|
|
|
memcpy(fs_info->super_for_commit, fs_info->super_copy,
|
|
|
|
sizeof(*fs_info->super_copy));
|
2007-06-29 03:57:36 +08:00
|
|
|
|
2019-03-25 20:31:22 +08:00
|
|
|
btrfs_commit_device_sizes(cur_trans);
|
2014-09-03 21:35:33 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
clear_bit(BTRFS_FS_LOG1_ERR, &fs_info->flags);
|
|
|
|
clear_bit(BTRFS_FS_LOG2_ERR, &fs_info->flags);
|
Btrfs: be aware of btree inode write errors to avoid fs corruption
While we have a transaction ongoing, the VM might decide at any time
to call btree_inode->i_mapping->a_ops->writepages(), which will start
writeback of dirty pages belonging to btree nodes/leafs. This call
might return an error or the writeback might finish with an error
before we attempt to commit the running transaction. If this happens,
we might have no way of knowing that such error happened when we are
committing the transaction - because the pages might no longer be
marked dirty nor tagged for writeback (if a subsequent modification
to the extent buffer didn't happen before the transaction commit) which
makes filemap_fdata[write|wait]_range unable to find such pages (even
if they're marked with SetPageError).
So if this happens we must abort the transaction, otherwise we commit
a super block with btree roots that point to btree nodes/leafs whose
content on disk is invalid - either garbage or the content of some
node/leaf from a past generation that got cowed or deleted and is no
longer valid (for this later case we end up getting error messages like
"parent transid verify failed on 10826481664 wanted 25748 found 29562"
when reading btree nodes/leafs from disk).
Note that setting and checking AS_EIO/AS_ENOSPC in the btree inode's
i_mapping would not be enough because we need to distinguish between
log tree extents (not fatal) vs non-log tree extents (fatal) and
because the next call to filemap_fdatawait_range() will catch and clear
such errors in the mapping - and that call might be from a log sync and
not from a transaction commit, which means we would not know about the
error at transaction commit time. Also, checking for the eb flag
EXTENT_BUFFER_IOERR at transaction commit time isn't done and would
not be completely reliable, as the eb might be removed from memory and
read back when trying to get it, which clears that flag right before
reading the eb's pages from disk, making us not know about the previous
write error.
Using the new 3 flags for the btree inode also makes us achieve the
goal of AS_EIO/AS_ENOSPC when writepages() returns success, started
writeback for all dirty pages and before filemap_fdatawait_range() is
called, the writeback for all dirty pages had already finished with
errors - because we were not using AS_EIO/AS_ENOSPC,
filemap_fdatawait_range() would return success, as it could not know
that writeback errors happened (the pages were no longer tagged for
writeback).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-26 19:25:56 +08:00
|
|
|
|
Btrfs: fix -ENOSPC when finishing block group creation
While creating a block group, we often end up getting ENOSPC while updating
the chunk tree, which leads to a transaction abortion that produces a trace
like the following:
[30670.116368] WARNING: CPU: 4 PID: 20735 at fs/btrfs/super.c:260 __btrfs_abort_transaction+0x52/0x106 [btrfs]()
[30670.117777] BTRFS: Transaction aborted (error -28)
(...)
[30670.163567] Call Trace:
[30670.163906] [<ffffffff8142fa46>] dump_stack+0x4f/0x7b
[30670.164522] [<ffffffff8108b6a2>] ? console_unlock+0x361/0x3ad
[30670.165171] [<ffffffff81045ea5>] warn_slowpath_common+0xa1/0xbb
[30670.166323] [<ffffffffa035daa7>] ? __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.167213] [<ffffffff81045f05>] warn_slowpath_fmt+0x46/0x48
[30670.167862] [<ffffffffa035daa7>] __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.169116] [<ffffffffa03743d7>] btrfs_create_pending_block_groups+0x101/0x130 [btrfs]
[30670.170593] [<ffffffffa038426a>] __btrfs_end_transaction+0x84/0x366 [btrfs]
[30670.171960] [<ffffffffa038455c>] btrfs_end_transaction+0x10/0x12 [btrfs]
[30670.174649] [<ffffffffa036eb6b>] btrfs_check_data_free_space+0x11f/0x27c [btrfs]
[30670.176092] [<ffffffffa039450d>] btrfs_fallocate+0x7c8/0xb96 [btrfs]
[30670.177218] [<ffffffff812459f2>] ? __this_cpu_preempt_check+0x13/0x15
[30670.178622] [<ffffffff81152447>] vfs_fallocate+0x14c/0x1de
[30670.179642] [<ffffffff8116b915>] ? __fget_light+0x2d/0x4f
[30670.180692] [<ffffffff81152863>] SyS_fallocate+0x47/0x62
[30670.186737] [<ffffffff81435b32>] system_call_fastpath+0x12/0x17
[30670.187792] ---[ end trace 0373e6b491c4a8cc ]---
This is because we don't do proper space reservation for the chunk block
reserve when we have multiple tasks allocating chunks in parallel.
So block group creation has 2 phases, and the first phase essentially
checks if there is enough space in the system space_info, allocating a
new system chunk if there isn't, while the second phase updates the
device, extent and chunk trees. However, because the updates to the
chunk tree happen in the second phase, if we have N tasks, each with
its own transaction handle, allocating new chunks in parallel and if
there is only enough space in the system space_info to allocate M chunks,
where M < N, none of the tasks ends up allocating a new system chunk in
the first phase and N - M tasks will get -ENOSPC when attempting to
update the chunk tree in phase 2 if they need to COW any nodes/leafs
from the chunk tree.
Fix this by doing proper reservation in the chunk block reserve.
The issue could be reproduced by running fstests generic/038 in a loop,
which eventually triggered the problem.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2015-05-20 21:01:54 +08:00
|
|
|
btrfs_trans_release_chunk_metadata(trans);
|
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
cur_trans->state = TRANS_STATE_UNBLOCKED;
|
2016-06-23 06:54:23 +08:00
|
|
|
fs_info->running_transaction = NULL;
|
|
|
|
spin_unlock(&fs_info->trans_lock);
|
|
|
|
mutex_unlock(&fs_info->reloc_mutex);
|
2009-03-13 08:12:45 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
wake_up(&fs_info->transaction_wait);
|
2008-07-18 00:53:50 +08:00
|
|
|
|
2018-02-07 23:55:50 +08:00
|
|
|
ret = btrfs_write_and_wait_transaction(trans);
|
2012-03-02 00:24:58 +08:00
|
|
|
if (ret) {
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_handle_fs_error(fs_info, ret,
|
|
|
|
"Error while writing out transaction");
|
2019-11-28 23:03:00 +08:00
|
|
|
/*
|
|
|
|
* reloc_mutex has been unlocked, tree_log_mutex is still held
|
|
|
|
* but we can't jump to unlock_tree_log causing double unlock
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_unlock(&fs_info->tree_log_mutex);
|
2014-02-19 19:24:16 +08:00
|
|
|
goto scrub_continue;
|
2012-03-02 00:24:58 +08:00
|
|
|
}
|
|
|
|
|
2017-02-11 02:04:32 +08:00
|
|
|
ret = write_all_supers(fs_info, 0);
|
2008-09-06 04:13:11 +08:00
|
|
|
/*
|
|
|
|
* the super is written, we can safely allow the tree-loggers
|
|
|
|
* to go about their business
|
|
|
|
*/
|
2016-06-23 06:54:23 +08:00
|
|
|
mutex_unlock(&fs_info->tree_log_mutex);
|
2017-12-20 14:42:26 +08:00
|
|
|
if (ret)
|
|
|
|
goto scrub_continue;
|
2008-09-06 04:13:11 +08:00
|
|
|
|
2018-03-15 22:00:26 +08:00
|
|
|
btrfs_finish_extent_commit(trans);
|
2008-01-03 22:08:48 +08:00
|
|
|
|
2015-09-24 22:46:10 +08:00
|
|
|
if (test_bit(BTRFS_TRANS_HAVE_FREE_BGS, &cur_trans->flags))
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_clear_space_info_full(fs_info);
|
btrfs: Fix out-of-space bug
Btrfs will report NO_SPACE when we create and remove files for several times,
and we can't write to filesystem until mount it again.
Steps to reproduce:
1: Create a single-dev btrfs fs with default option
2: Write a file into it to take up most fs space
3: Delete above file
4: Wait about 100s to let chunk removed
5: goto 2
Script is like following:
#!/bin/bash
# Recommend 1.2G space, too large disk will make test slow
DEV="/dev/sda16"
MNT="/mnt/tmp"
dev_size="$(lsblk -bn -o SIZE "$DEV")" || exit 2
file_size_m=$((dev_size * 75 / 100 / 1024 / 1024))
echo "Loop write ${file_size_m}M file on $((dev_size / 1024 / 1024))M dev"
for ((i = 0; i < 10; i++)); do umount "$MNT" 2>/dev/null; done
echo "mkfs $DEV"
mkfs.btrfs -f "$DEV" >/dev/null || exit 2
echo "mount $DEV $MNT"
mount "$DEV" "$MNT" || exit 2
for ((loop_i = 0; loop_i < 20; loop_i++)); do
echo
echo "loop $loop_i"
echo "dd file..."
cmd=(dd if=/dev/zero of="$MNT"/file0 bs=1M count="$file_size_m")
"${cmd[@]}" 2>/dev/null || {
# NO_SPACE error triggered
echo "dd failed: ${cmd[*]}"
exit 1
}
echo "rm file..."
rm -f "$MNT"/file0 || exit 2
for ((i = 0; i < 10; i++)); do
df "$MNT" | tail -1
sleep 10
done
done
Reason:
It is triggered by commit: 47ab2a6c689913db23ccae38349714edf8365e0a
which is used to remove empty block groups automatically, but the
reason is not in that patch. Code before works well because btrfs
don't need to create and delete chunks so many times with high
complexity.
Above bug is caused by many reason, any of them can trigger it.
Reason1:
When we remove some continuous chunks but leave other chunks after,
these disk space should be used by chunk-recreating, but in current
code, only first create will successed.
Fixed by Forrest Liu <forrestl@synology.com> in:
Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole
Reason2:
contains_pending_extent() return wrong value in calculation.
Fixed by Forrest Liu <forrestl@synology.com> in:
Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole
Reason3:
btrfs_check_data_free_space() try to commit transaction and retry
allocating chunk when the first allocating failed, but space_info->full
is set in first allocating, and prevent second allocating in retry.
Fixed in this patch by clear space_info->full in commit transaction.
Tested for severial times by above script.
Changelog v3->v4:
use light weight int instead of atomic_t to record have_remove_bgs in
transaction, suggested by:
Josef Bacik <jbacik@fb.com>
Changelog v2->v3:
v2 fixed the bug by adding more commit-transaction, but we
only need to reclaim space when we are really have no space for
new chunk, noticed by:
Filipe David Manana <fdmanana@gmail.com>
Actually, our code already have this type of commit-and-retry,
we only need to make it working with removed-bgs.
v3 fixed the bug with above way.
Changelog v1->v2:
v1 will introduce a new bug when delete and create chunk in same disk
space in same transaction, noticed by:
Filipe David Manana <fdmanana@gmail.com>
V2 fix this bug by commit transaction after remove block grops.
Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Suggested-by: Filipe David Manana <fdmanana@gmail.com>
Suggested-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Chris Mason <clm@fb.com>
2015-02-12 14:18:17 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
fs_info->last_trans_committed = cur_trans->transid;
|
Btrfs: make the state of the transaction more readable
We used 3 variants to track the state of the transaction, it was complex
and wasted the memory space. Besides that, it was hard to understand that
which types of the transaction handles should be blocked in each transaction
state, so the developers often made mistakes.
This patch improved the above problem. In this patch, we define 6 states
for the transaction,
enum btrfs_trans_state {
TRANS_STATE_RUNNING = 0,
TRANS_STATE_BLOCKED = 1,
TRANS_STATE_COMMIT_START = 2,
TRANS_STATE_COMMIT_DOING = 3,
TRANS_STATE_UNBLOCKED = 4,
TRANS_STATE_COMPLETED = 5,
TRANS_STATE_MAX = 6,
}
and just use 1 variant to track those state.
In order to make the blocked handle types for each state more clear,
we introduce a array:
unsigned int btrfs_blocked_trans_types[TRANS_STATE_MAX] = {
[TRANS_STATE_RUNNING] = 0U,
[TRANS_STATE_BLOCKED] = (__TRANS_USERSPACE |
__TRANS_START),
[TRANS_STATE_COMMIT_START] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH),
[TRANS_STATE_COMMIT_DOING] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN),
[TRANS_STATE_UNBLOCKED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
[TRANS_STATE_COMPLETED] = (__TRANS_USERSPACE |
__TRANS_START |
__TRANS_ATTACH |
__TRANS_JOIN |
__TRANS_JOIN_NOLOCK),
}
it is very intuitionistic.
Besides that, because we remove ->in_commit in transaction structure, so
the lock ->commit_lock which was used to protect it is unnecessary, remove
->commit_lock.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2013-05-17 11:53:43 +08:00
|
|
|
/*
|
|
|
|
* We needn't acquire the lock here because there is no other task
|
|
|
|
* which can change it.
|
|
|
|
*/
|
|
|
|
cur_trans->state = TRANS_STATE_COMPLETED;
|
2007-04-02 22:50:19 +08:00
|
|
|
wake_up(&cur_trans->commit_wait);
|
2008-11-18 10:02:50 +08:00
|
|
|
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
2011-04-12 03:45:29 +08:00
|
|
|
list_del_init(&cur_trans->list);
|
2016-06-23 06:54:23 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2011-04-12 05:25:13 +08:00
|
|
|
|
2013-09-30 23:36:38 +08:00
|
|
|
btrfs_put_transaction(cur_trans);
|
|
|
|
btrfs_put_transaction(cur_trans);
|
2007-08-30 03:47:34 +08:00
|
|
|
|
2013-05-15 15:48:27 +08:00
|
|
|
if (trans->type & __TRANS_FREEZABLE)
|
2016-06-23 06:54:23 +08:00
|
|
|
sb_end_intwrite(fs_info->sb);
|
2012-06-12 22:20:45 +08:00
|
|
|
|
2016-09-10 09:39:03 +08:00
|
|
|
trace_btrfs_transaction_commit(trans->root);
|
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 19:18:59 +08:00
|
|
|
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_scrub_continue(fs_info);
|
2011-03-08 21:14:00 +08:00
|
|
|
|
2009-09-12 04:12:44 +08:00
|
|
|
if (current->journal_info == trans)
|
|
|
|
current->journal_info = NULL;
|
|
|
|
|
2007-04-02 22:50:19 +08:00
|
|
|
kmem_cache_free(btrfs_trans_handle_cachep, trans);
|
2009-11-12 17:36:34 +08:00
|
|
|
|
2007-03-23 03:59:16 +08:00
|
|
|
return ret;
|
2012-03-02 00:24:58 +08:00
|
|
|
|
2019-11-28 23:03:00 +08:00
|
|
|
unlock_tree_log:
|
|
|
|
mutex_unlock(&fs_info->tree_log_mutex);
|
|
|
|
unlock_reloc:
|
|
|
|
mutex_unlock(&fs_info->reloc_mutex);
|
2014-02-19 19:24:16 +08:00
|
|
|
scrub_continue:
|
2016-06-23 06:54:24 +08:00
|
|
|
btrfs_scrub_continue(fs_info);
|
2012-03-02 00:24:58 +08:00
|
|
|
cleanup_transaction:
|
2018-02-07 23:55:39 +08:00
|
|
|
btrfs_trans_release_metadata(trans);
|
2019-01-24 00:09:16 +08:00
|
|
|
btrfs_cleanup_pending_block_groups(trans);
|
Btrfs: fix -ENOSPC when finishing block group creation
While creating a block group, we often end up getting ENOSPC while updating
the chunk tree, which leads to a transaction abortion that produces a trace
like the following:
[30670.116368] WARNING: CPU: 4 PID: 20735 at fs/btrfs/super.c:260 __btrfs_abort_transaction+0x52/0x106 [btrfs]()
[30670.117777] BTRFS: Transaction aborted (error -28)
(...)
[30670.163567] Call Trace:
[30670.163906] [<ffffffff8142fa46>] dump_stack+0x4f/0x7b
[30670.164522] [<ffffffff8108b6a2>] ? console_unlock+0x361/0x3ad
[30670.165171] [<ffffffff81045ea5>] warn_slowpath_common+0xa1/0xbb
[30670.166323] [<ffffffffa035daa7>] ? __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.167213] [<ffffffff81045f05>] warn_slowpath_fmt+0x46/0x48
[30670.167862] [<ffffffffa035daa7>] __btrfs_abort_transaction+0x52/0x106 [btrfs]
[30670.169116] [<ffffffffa03743d7>] btrfs_create_pending_block_groups+0x101/0x130 [btrfs]
[30670.170593] [<ffffffffa038426a>] __btrfs_end_transaction+0x84/0x366 [btrfs]
[30670.171960] [<ffffffffa038455c>] btrfs_end_transaction+0x10/0x12 [btrfs]
[30670.174649] [<ffffffffa036eb6b>] btrfs_check_data_free_space+0x11f/0x27c [btrfs]
[30670.176092] [<ffffffffa039450d>] btrfs_fallocate+0x7c8/0xb96 [btrfs]
[30670.177218] [<ffffffff812459f2>] ? __this_cpu_preempt_check+0x13/0x15
[30670.178622] [<ffffffff81152447>] vfs_fallocate+0x14c/0x1de
[30670.179642] [<ffffffff8116b915>] ? __fget_light+0x2d/0x4f
[30670.180692] [<ffffffff81152863>] SyS_fallocate+0x47/0x62
[30670.186737] [<ffffffff81435b32>] system_call_fastpath+0x12/0x17
[30670.187792] ---[ end trace 0373e6b491c4a8cc ]---
This is because we don't do proper space reservation for the chunk block
reserve when we have multiple tasks allocating chunks in parallel.
So block group creation has 2 phases, and the first phase essentially
checks if there is enough space in the system space_info, allocating a
new system chunk if there isn't, while the second phase updates the
device, extent and chunk trees. However, because the updates to the
chunk tree happen in the second phase, if we have N tasks, each with
its own transaction handle, allocating new chunks in parallel and if
there is only enough space in the system space_info to allocate M chunks,
where M < N, none of the tasks ends up allocating a new system chunk in
the first phase and N - M tasks will get -ENOSPC when attempting to
update the chunk tree in phase 2 if they need to COW any nodes/leafs
from the chunk tree.
Fix this by doing proper reservation in the chunk block reserve.
The issue could be reproduced by running fstests generic/038 in a loop,
which eventually triggered the problem.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2015-05-20 21:01:54 +08:00
|
|
|
btrfs_trans_release_chunk_metadata(trans);
|
2012-06-27 04:13:18 +08:00
|
|
|
trans->block_rsv = NULL;
|
2016-06-23 06:54:23 +08:00
|
|
|
btrfs_warn(fs_info, "Skipping commit of aborted transaction.");
|
2012-03-02 00:24:58 +08:00
|
|
|
if (current->journal_info == trans)
|
|
|
|
current->journal_info = NULL;
|
2018-02-07 23:55:46 +08:00
|
|
|
cleanup_transaction(trans, ret);
|
2012-03-02 00:24:58 +08:00
|
|
|
|
|
|
|
return ret;
|
2007-03-23 03:59:16 +08:00
|
|
|
}
|
|
|
|
|
2008-09-30 03:18:18 +08:00
|
|
|
/*
|
2013-03-12 23:13:28 +08:00
|
|
|
* return < 0 if error
|
|
|
|
* 0 if there are no more dead_roots at the time of call
|
|
|
|
* 1 there are more to be processed, call me again
|
|
|
|
*
|
|
|
|
* The return value indicates there are certainly more snapshots to delete, but
|
|
|
|
* if there comes a new one during processing, it may return 0. We don't mind,
|
|
|
|
* because btrfs_commit_super will poke cleaner thread and it will process it a
|
|
|
|
* few seconds later.
|
2008-09-30 03:18:18 +08:00
|
|
|
*/
|
2013-03-12 23:13:28 +08:00
|
|
|
int btrfs_clean_one_deleted_snapshot(struct btrfs_root *root)
|
2007-08-11 02:06:19 +08:00
|
|
|
{
|
2013-03-12 23:13:28 +08:00
|
|
|
int ret;
|
Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
When a tree block in subvolume tree is cow'd, the reference counts of all
extents it points to are increased by one. At transaction commit time,
the old root of the subvolume is recorded in a "dead root" data structure,
and the btree it points to is later walked, dropping reference counts
and freeing any blocks where the reference count goes to 0.
The increments done during cow and decrements done after commit cancel out,
and the walk is a very expensive way to go about freeing the blocks that
are no longer referenced by the new btree root. This commit reduces the
transaction overhead by avoiding the need for dead root records.
When a non-shared tree block is cow'd, we free the old block at once, and the
new block inherits old block's references. When a tree block with reference
count > 1 is cow'd, we increase the reference counts of all extents
the new block points to by one, and decrease the old block's reference count by
one.
This dead tree avoidance code removes the need to modify the reference
counts of lower level extents when a non-shared tree block is cow'd.
But we still need to update back ref for all pointers in the block.
This is because the location of the block is recorded in the back ref
item.
We can solve this by introducing a new type of back ref. The new
back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer
by searching the tree. The shortcoming of the new back ref is that it
only works for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these
fuzzy back references would be O(number_of_snapshots) and quite slow.
The solution used here is to use the fuzzy back references in the common
case where a given tree block is only referenced by one root,
and use the full back references when multiple roots have a reference
on a given block.
This commit adds per subvolume red-black tree to keep trace of cached
inodes. The red-black tree helps the balancing code to find cached
inodes whose inode numbers within a given range.
This commit improves the balancing code by introducing several data
structures to keep the state of balancing. The most important one
is the back ref cache. It caches how the upper level tree blocks are
referenced. This greatly reduce the overhead of checking back ref.
The improved balancing code scales significantly better with a large
number of snapshots.
This is a very large commit and was written in a number of
pieces. But, they depend heavily on the disk format change and were
squashed together to make sure git bisect didn't end up in a
bad state wrt space balancing or the format change.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2009-06-10 22:45:14 +08:00
|
|
|
struct btrfs_fs_info *fs_info = root->fs_info;
|
|
|
|
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_lock(&fs_info->trans_lock);
|
2013-03-12 23:13:28 +08:00
|
|
|
if (list_empty(&fs_info->dead_roots)) {
|
|
|
|
spin_unlock(&fs_info->trans_lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
root = list_first_entry(&fs_info->dead_roots,
|
|
|
|
struct btrfs_root, root_list);
|
2013-07-26 03:11:47 +08:00
|
|
|
list_del_init(&root->root_list);
|
2011-04-12 05:25:13 +08:00
|
|
|
spin_unlock(&fs_info->trans_lock);
|
2007-08-11 02:06:19 +08:00
|
|
|
|
2018-08-06 13:25:24 +08:00
|
|
|
btrfs_debug(fs_info, "cleaner removing %llu", root->root_key.objectid);
|
2009-09-22 04:00:26 +08:00
|
|
|
|
2013-03-12 23:13:28 +08:00
|
|
|
btrfs_kill_all_delayed_nodes(root);
|
2020-02-15 05:11:41 +08:00
|
|
|
if (root->ino_cache_inode) {
|
|
|
|
iput(root->ino_cache_inode);
|
|
|
|
root->ino_cache_inode = NULL;
|
|
|
|
}
|
btrfs: implement delayed inode items operation
Changelog V5 -> V6:
- Fix oom when the memory load is high, by storing the delayed nodes into the
root's radix tree, and letting btrfs inodes go.
Changelog V4 -> V5:
- Fix the race on adding the delayed node to the inode, which is spotted by
Chris Mason.
- Merge Chris Mason's incremental patch into this patch.
- Fix deadlock between readdir() and memory fault, which is reported by
Itaru Kitayama.
Changelog V3 -> V4:
- Fix nested lock, which is reported by Itaru Kitayama, by updating space cache
inode in time.
Changelog V2 -> V3:
- Fix the race between the delayed worker and the task which does delayed items
balance, which is reported by Tsutomu Itoh.
- Modify the patch address David Sterba's comment.
- Fix the bug of the cpu recursion spinlock, reported by Chris Mason
Changelog V1 -> V2:
- break up the global rb-tree, use a list to manage the delayed nodes,
which is created for every directory and file, and used to manage the
delayed directory name index items and the delayed inode item.
- introduce a worker to deal with the delayed nodes.
Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree insertions,
such as inode item, directory name item, directory name index and so on.
If we can do some delayed b+ tree insertion or deletion, we can improve the
performance, so we made this patch which implemented delayed directory name
index insertion/deletion and delayed inode update.
Implementation:
- introduce a delayed root object into the filesystem, that use two lists to
manage the delayed nodes which are created for every file/directory.
One is used to manage all the delayed nodes that have delayed items. And the
other is used to manage the delayed nodes which is waiting to be dealt with
by the work thread.
- Every delayed node has two rb-tree, one is used to manage the directory name
index which is going to be inserted into b+ tree, and the other is used to
manage the directory name index which is going to be deleted from b+ tree.
- introduce a worker to deal with the delayed operation. This worker is used
to deal with the works of the delayed directory name index items insertion
and deletion and the delayed inode update.
When the delayed items is beyond the lower limit, we create works for some
delayed nodes and insert them into the work queue of the worker, and then
go back.
When the delayed items is beyond the upper bound, we create works for all
the delayed nodes that haven't been dealt with, and insert them into the work
queue of the worker, and then wait for that the untreated items is below some
threshold value.
- When we want to insert a directory name index into b+ tree, we just add the
information into the delayed inserting rb-tree.
And then we check the number of the delayed items and do delayed items
balance. (The balance policy is above.)
- When we want to delete a directory name index from the b+ tree, we search it
in the inserting rb-tree at first. If we look it up, just drop it. If not,
add the key of it into the delayed deleting rb-tree.
Similar to the delayed inserting rb-tree, we also check the number of the
delayed items and do delayed items balance.
(The same to inserting manipulation)
- When we want to update the metadata of some inode, we cached the data of the
inode into the delayed node. the worker will flush it into the b+ tree after
dealing with the delayed insertion and deletion.
- We will move the delayed node to the tail of the list after we access the
delayed node, By this way, we can cache more delayed items and merge more
inode updates.
- If we want to commit transaction, we will deal with all the delayed node.
- the delayed node will be freed when we free the btrfs inode.
- Before we log the inode items, we commit all the directory name index items
and the delayed inode update.
I did a quick test by the benchmark tool[1] and found we can improve the
performance of file creation by ~15%, and file deletion by ~20%.
Before applying this patch:
Create files:
Total files: 50000
Total time: 1.096108
Average time: 0.000022
Delete files:
Total files: 50000
Total time: 1.510403
Average time: 0.000030
After applying this patch:
Create files:
Total files: 50000
Total time: 0.932899
Average time: 0.000019
Delete files:
Total files: 50000
Total time: 1.215732
Average time: 0.000024
[1] http://marc.info/?l=linux-btrfs&m=128212635122920&q=p3
Many thanks for Kitayama-san's help!
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Reviewed-by: David Sterba <dave@jikos.cz>
Tested-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Tested-by: Itaru Kitayama <kitayama@cl.bb4u.ne.jp>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-04-22 18:12:22 +08:00
|
|
|
|
2013-03-12 23:13:28 +08:00
|
|
|
if (btrfs_header_backref_rev(root->node) <
|
|
|
|
BTRFS_MIXED_BACKREF_REV)
|
2020-03-10 17:43:51 +08:00
|
|
|
ret = btrfs_drop_snapshot(root, 0, 0);
|
2013-03-12 23:13:28 +08:00
|
|
|
else
|
2020-03-10 17:43:51 +08:00
|
|
|
ret = btrfs_drop_snapshot(root, 1, 0);
|
2014-02-05 09:03:47 +08:00
|
|
|
|
2020-02-15 05:11:44 +08:00
|
|
|
btrfs_put_root(root);
|
2013-07-31 22:28:05 +08:00
|
|
|
return (ret < 0) ? 0 : 1;
|
2007-08-11 02:06:19 +08:00
|
|
|
}
|
2014-02-05 22:26:17 +08:00
|
|
|
|
|
|
|
void btrfs_apply_pending_changes(struct btrfs_fs_info *fs_info)
|
|
|
|
{
|
|
|
|
unsigned long prev;
|
|
|
|
unsigned long bit;
|
|
|
|
|
2015-01-20 17:05:33 +08:00
|
|
|
prev = xchg(&fs_info->pending_changes, 0);
|
2014-02-05 22:26:17 +08:00
|
|
|
if (!prev)
|
|
|
|
return;
|
|
|
|
|
2014-02-05 22:26:17 +08:00
|
|
|
bit = 1 << BTRFS_PENDING_SET_INODE_MAP_CACHE;
|
|
|
|
if (prev & bit)
|
|
|
|
btrfs_set_opt(fs_info->mount_opt, INODE_MAP_CACHE);
|
|
|
|
prev &= ~bit;
|
|
|
|
|
|
|
|
bit = 1 << BTRFS_PENDING_CLEAR_INODE_MAP_CACHE;
|
|
|
|
if (prev & bit)
|
|
|
|
btrfs_clear_opt(fs_info->mount_opt, INODE_MAP_CACHE);
|
|
|
|
prev &= ~bit;
|
|
|
|
|
2014-11-12 21:24:35 +08:00
|
|
|
bit = 1 << BTRFS_PENDING_COMMIT;
|
|
|
|
if (prev & bit)
|
|
|
|
btrfs_debug(fs_info, "pending commit done");
|
|
|
|
prev &= ~bit;
|
|
|
|
|
2014-02-05 22:26:17 +08:00
|
|
|
if (prev)
|
|
|
|
btrfs_warn(fs_info,
|
|
|
|
"unknown pending changes left 0x%lx, ignoring", prev);
|
|
|
|
}
|