linux.git/fs/btrfs/backref.c, branch v3.15

Btrfs: remove transaction from send

2014-04-07T00:39:30+00:00

Lets try this again.  We can deadlock the box if we send on a box and try to
write onto the same fs with the app that is trying to listen to the send pipe.
This is because the writer could get stuck waiting for a transaction commit
which is being blocked by the send.  So fix this by making sure looking at the
commit roots is always going to be consistent.  We do this by keeping track of
which roots need to have their commit roots swapped during commit, and then
taking the commit_root_sem and swapping them all at once.  Then make sure we
take a read lock on the commit_root_sem in cases where we search the commit root
to make sure we're always looking at a consistent view of the commit roots.
Previously we had problems with this because we would swap a fs tree commit root
and then swap the extent tree commit root independently which would cause the
backref walking code to screw up sometimes.  With this patch we no longer
deadlock and pass all the weird send/receive corner cases.  Thanks,

Reportedy-by: Hugo Mills 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: take into account total references when doing backref lookup

2014-03-21T22:28:09+00:00

I added an optimization for large files where we would stop searching for
backrefs once we had looked at the number of references we currently had for
this extent.  This works great most of the time, but for snapshots that point to
this extent and has changes in the original root this assumption falls on it
face.  So keep track of any delayed ref mods made and add in the actual ref
count as reported by the extent item and use that to limit how far down an inode
we'll search for extents.  Thanks,

Reportedy-by: Hugo Mills 
Signed-off-by: Josef Bacik 
Reported-by: Hugo Mills 
Tested-by: Hugo Mills 
Signed-off-by: Chris Mason

Btrfs: skip locking when searching commit root

2014-03-10T19:16:55+00:00

We won't change commit root, skip locking dance with commit root
when walking backrefs, this can speed up btrfs send operations.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik

Btrfs: switch to btrfs_previous_extent_item()

2014-03-10T19:15:54+00:00

Since we have introduced btrfs_previous_extent_item() to search previous
extent item, just switch into it.

Signed-off-by: Wang Shilong 
Reviewed-by: Filipe Manana 
Signed-off-by: Josef Bacik

Btrfs: only add roots if necessary in find_parent_nodes()

2014-03-10T19:15:41+00:00

find_all_leafs() dosen't need add all roots actually, add roots only
if we need, this can avoid unnecessary ulist dance.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik

Btrfs: fix memory leaks on walking backrefs failure

2014-01-29T15:06:26+00:00

When walking backrefs, we may iterate every inode's extent
and add/merge them into ulist, and the caller will free memory
from ulist.

However, if we fail to allocate inode's extents element
memory or ulist_add() fail to allocate memory, we won't
add allocated memory into ulist, and the caller won't
free some allocated memory thus memory leaks happen.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: add a reschedule point in btrfs_find_all_roots()

2014-01-29T15:06:25+00:00

I can easily trigger the following warnings when enabling quota
in my virtual machine(running Opensuse), Steps are firstly creating
a subvolume full of fragment extents, and then create many snapshots
(500 in my test case).

[ 2362.808459] BUG: soft lockup - CPU#0 stuck for 22s! [btrfs-qgroup-re:1970]

[ 2362.809023] task: e4af8450 ti: e371c000 task.ti: e371c000
[ 2362.809026] EIP: 0060:[] EFLAGS: 00000246 CPU: 0
[ 2362.809049] EIP is at __merge_refs+0x5e/0x100 [btrfs]
[ 2362.809051] EAX: 00000000 EBX: cfadbcf0 ECX: 00000000 EDX: cfadbcb0
[ 2362.809052] ESI: dd8d3370 EDI: e371dde0 EBP: e371dd6c ESP: e371dd5c
[ 2362.809054]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 2362.809055] CR0: 80050033 CR2: ac454d50 CR3: 009a9000 CR4: 001407d0
[ 2362.809099] Stack:
[ 2362.809100]  00000001 e371dde0 dfcc6890 f29f8000 e371de28 fa39016d 00000011 00000001
[ 2362.809105]  99bfc000 00000000 93928000 00000000 00000001 00000050 e371dda8 00000001
[ 2362.809109]  f3a31000 f3413000 00000001 e371ddb8 000040a8 00000202 00000000 00000023
[ 2362.809113] Call Trace:
[ 2362.809136]  [] find_parent_nodes+0x34d/0x1280 [btrfs]
[ 2362.809156]  [] btrfs_find_all_roots+0xb2/0x110 [btrfs]
[ 2362.809174]  [] btrfs_qgroup_rescan_worker+0x358/0x7a0 [btrfs]
[ 2362.809180]  [] ? lock_timer_base.isra.39+0x1e/0x40
[ 2362.809199]  [] worker_loop+0xff/0x470 [btrfs]
[ 2362.809204]  [] ? __wake_up_locked+0x1a/0x20
[ 2362.809221]  [] ? btrfs_queue_worker+0x2b0/0x2b0 [btrfs]
[ 2362.809225]  [] kthread+0x9c/0xb0
[ 2362.809229]  [] ret_from_kernel_thread+0x1b/0x30
[ 2362.809233]  [] ? kthread_create_on_node+0x110/0x110

By adding a reschedule point at the end of btrfs_find_all_roots(), i no longer
hit these warnings.

Cc: Josef Bacik 
Signed-off-by: Wang Shilong 
Reviewed-by: David Sterba 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: fix to catch all errors when resolving indirect ref

2014-01-29T15:06:23+00:00

We can only tolerate ENOENT here, for other errors, we should
return directly.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: fix protection between walking backrefs and root deletion

2014-01-29T15:06:23+00:00

There is a race condition between resolving indirect ref and root deletion,
and we should gurantee that root can not be destroyed to avoid accessing
broken tree here.

Here we fix it by holding @subvol_srcu, and we will release it as soon
as we have held root node lock.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: only process as many file extents as there are refs

2014-01-28T21:20:28+00:00

The backref walking code will search down to the key it is looking for and then
proceed to walk _all_ of the extents on the file until it hits the end.  This is
suboptimal with large files, we only need to look for as many extents as we have
references for that inode.  I have a testcase that creates a randomly written 4
gig file and before this patch it took 6min 30sec to do the initial send, with
this patch it takes 2min 30sec to do the intial send.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason