linux.git/fs/btrfs/relocation.c, branch v3.13

Btrfs: make sure we cleanup all reloc roots if error happens

2013-12-12T15:12:51+00:00

I hit an oops when merging reloc roots fails, the reason is that
new reloc roots may be added and we should make sure we cleanup
all reloc roots.

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

Btrfs: skip building backref tree for uuid and quota tree when doing balance relocation

2013-12-12T15:12:36+00:00

Quota tree and UUID Tree is only cowed, they can not be snapshoted.

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

Btrfs: fix an oops when doing balance relocation

2013-12-12T15:12:20+00:00

I hit an oops when inserting reloc root into @reloc_root_tree(it can be
easily triggered when forcing cow for relocation root)

[  866.494539]  [] btrfs_init_reloc_root+0x79/0xb0 [btrfs]
[  866.495321]  [] record_root_in_trans+0xb0/0x110 [btrfs]
[  866.496109]  [] btrfs_record_root_in_trans+0x48/0x80 [btrfs]
[  866.496908]  [] select_reloc_root+0xa8/0x210 [btrfs]
[  866.497703]  [] do_relocation+0x16a/0x540 [btrfs]

This is because reloc root inserted into @reloc_root_tree is not within one
transaction,reloc root may be cowed and root block bytenr will be reused then
oops happens.We should update reloc root in @reloc_root_tree when cow reloc
root node, fix it.

Signed-off-by: Wang Shilong 
Reviewed-by: Miao Xie 
Signed-off-by: Chris Mason

Btrfs: rename btrfs_start_all_delalloc_inodes

2013-11-12T03:13:58+00:00

rename the function -- btrfs_start_all_delalloc_inodes(), and make its
name be compatible to btrfs_wait_ordered_roots(), since they are always
used at the same place.

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

Btrfs: don't wait for the completion of all the ordered extents

2013-11-12T03:13:44+00:00

It is very likely that there are lots of ordered extents in the filesytem,
if we wait for the completion of all of them when we want to reclaim some
space for the metadata space reservation, we would be blocked for a long
time. The performance would drop down suddenly for a long time.

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

btrfs: Use WARN_ON()'s return value in place of WARN_ON(1)

2013-11-12T03:11:53+00:00

Use WARN_ON()'s return value in place of WARN_ON(1) for cleaner source
code that outputs a more descriptive warnings. Also fix the styling
warning of redundant braces that came up as a result of this fix.

Signed-off-by: Dulshani Gunawardhana 
Reviewed-by: Zach Brown 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: use 'u64' rather than 'int' to get extent's generation

2013-11-12T03:10:06+00:00

We define a 'int' to get extent's generation by mistake,fix it.

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

Btrfs: stop committing the transaction so much during relocate

2013-11-12T03:08:31+00:00

I noticed with my horrible snapshot excercisor that we were taking forever to
relocate the larger the file system got.  This appeared to be because we were
committing the transaction _constantly_.  There were a few places where we do
braindead things with metadata reservation, like start a transaction and then
try to refill the block rsv, which not only keeps us from committing a
transaction during the enospc stuff, but keeps us from doing some of the harder
flushing work which will make us more likely to need to commit the transaction.
We also were checking the block rsv and committing the transaction if the block
rsv was below a certain threshold, but we were doing this in a place where we
don't actually keep anything in the block rsv so this was always ending up false
so we always committed the transaction in this case.  I tested this to make sure
it didn't break anything, but it takes about 10 hours to get the box to this
state so I don't know how much of an impact it will really make.  Thanks,

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

Btrfs: return an error from btrfs_wait_ordered_range

2013-11-12T03:07:35+00:00

I noticed that if the free space cache has an error writing out it's data it
won't actually error out, it will just carry on.  This is because it doesn't
check the return value of btrfs_wait_ordered_range, which didn't actually return
anything.  So fix this in order to keep us from making free space cache look
valid when it really isnt.  Thanks,

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

Btrfs: fix BUG_ON() casued by the reserved space migration

2013-11-12T02:54:28+00:00

When we did space balance and snapshot creation at the same time, we might
meet the following oops:
 kernel BUG at fs/btrfs/inode.c:3038!
 [SNIP]
 Call Trace:
 [] btrfs_orphan_cleanup+0x293/0x407 [btrfs]
 [] btrfs_mksubvol.isra.28+0x259/0x373 [btrfs]
 [] btrfs_ioctl_snap_create_transid+0x126/0x156 [btrfs]
 [] btrfs_ioctl_snap_create_v2+0xd0/0x121 [btrfs]
 [] btrfs_ioctl+0x414/0x1854 [btrfs]
 [] ? __do_page_fault+0x305/0x379
 [] vfs_ioctl+0x1d/0x39
 [] do_vfs_ioctl+0x32d/0x3e2
 [] ? finish_task_switch+0x80/0xb8
 [] SyS_ioctl+0x57/0x83
 [] ? do_device_not_available+0x12/0x14
 [] system_call_fastpath+0x16/0x1b
 [SNIP]
 RIP  [] btrfs_orphan_add+0xc3/0x126 [btrfs]

The reason of the problem is that the relocation root creation stole
the reserved space, which was reserved for orphan item deletion.

There are several ways to fix this problem, one is to increasing
the reserved space size of the space balace, and then we can use
that space to create the relocation tree for each fs/file trees.
But it is hard to calculate the suitable size because we doesn't
know how many fs/file trees we need relocate.

We fixed this problem by reserving the space for relocation root creation
actively since the space it need is very small (one tree block, used for
root node copy), then we use that reserved space to create the
relocation tree. If we don't reserve space for relocation tree creation,
we will use the reserved space of the balance.

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