linux-stable.git/fs/btrfs/relocation.c, branch linux-3.12.y

Btrfs: fix build_backref_tree issue with multiple shared blocks

2014-10-31T14:11:05+00:00

commit bbe9051441effce51c9a533d2c56440df64db2d7 upstream.

Marc Merlin sent me a broken fs image months ago where it would blow up in the
upper->checked BUG_ON() in build_backref_tree.  This is because we had a
scenario like this

block a -- level 4 (not shared)
   |
block b -- level 3 (reloc block, shared)
   |
block c -- level 2 (not shared)
   |
block d -- level 1 (shared)
   |
block e -- level 0 (shared)

We go to build a backref tree for block e, we notice block d is shared and add
it to the list of blocks to lookup it's backrefs for.  Now when we loop around
we will check edges for the block, so we will see we looked up block c last
time.  So we lookup block d and then see that the block that points to it is
block c and we can just skip that edge since we've already been up this path.
The problem is because we clear need_check when we see block d (as it is shared)
we never add block b as needing to be checked.  And because block c is in our
path already we bail out before we walk up to block b and add it to the backref
check list.

To fix this we need to reset need_check if we trip over a block that doesn't
need to be checked.  This will make sure that any subsequent blocks in the path
as we're walking up afterwards are added to the list to be processed.  With this
patch I can now mount Marc's fs image and it'll complete the balance without
panicing.  Thanks,

Reported-by: Marc MERLIN 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason 
Signed-off-by: Jiri Slaby

Btrfs: cleanup error handling in build_backref_tree

2014-10-31T14:11:05+00:00

commit 75bfb9aff45e44625260f52a5fd581b92ace3e62 upstream.

When balance panics it tends to panic in the

BUG_ON(!upper->checked);

test, because it means it couldn't build the backref tree properly.  This is
annoying to users and frankly a recoverable error, nothing in this function is
actually fatal since it is just an in-memory building of the backrefs for a
given bytenr.  So go through and change all the BUG_ON()'s to ASSERT()'s, and
fix the BUG_ON(!upper->checked) thing to just return an error.

This patch also fixes the error handling so it tears down the work we've done
properly.  This code was horribly broken since we always just panic'ed instead
of actually erroring out, so it needed to be completely re-worked.  With this
patch my broken image no longer panics when I mount it.  Thanks,

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

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

2014-06-27T08:25:23+00:00

commit 20dd2cbf01888a91fdd921403040a710b275a1ff upstream.

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 
Signed-off-by: Jiri Slaby

Btrfs: relocate csums properly with prealloc extents

2013-11-29T19:27:52+00:00

commit 4577b014d1bc3db386da3246f625888fc48083a9 upstream.

A user reported a problem where they were getting csum errors when running a
balance and running systemd's journal.  This is because systemd is awesome and
fallocate()'s its log space and writes into it.  Unfortunately we assume that
when we read in all the csums for an extent that they are sequential starting at
the bytenr we care about.  This obviously isn't the case for prealloc extents,
where we could have written to the middle of the prealloc extent only, which
means the csum would be for the bytenr in the middle of our range and not the
front of our range.  Fix this by offsetting the new bytenr we are logging to
based on the original bytenr the csum was for.  With this patch I no longer see
the csum errors I was seeing.  Thanks,

Reported-by: Chris Murphy 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix oops caused by the space balance and dead roots

2013-10-11T01:31:02+00:00

When doing space balance and subvolume destroy at the same time, we met
the following oops:

kernel BUG at fs/btrfs/relocation.c:2247!
RIP: 0010: [] prepare_to_merge+0x154/0x1f0 [btrfs]
Call Trace:
 [] relocate_block_group+0x466/0x4e6 [btrfs]
 [] btrfs_relocate_block_group+0x143/0x275 [btrfs]
 [] btrfs_relocate_chunk.isra.27+0x5c/0x5a2 [btrfs]
 [] ? btrfs_item_key_to_cpu+0x15/0x31 [btrfs]
 [] ? btrfs_get_token_64+0x7e/0xcd [btrfs]
 [] ? btrfs_tree_read_unlock_blocking+0xb2/0xb7 [btrfs]
 [] btrfs_balance+0x9c7/0xb6f [btrfs]
 [] btrfs_ioctl_balance+0x234/0x2ac [btrfs]
 [] btrfs_ioctl+0xd87/0x1ef9 [btrfs]
 [] ? path_openat+0x234/0x4db
 [] ? __do_page_fault+0x31d/0x391
 [] ? vma_link+0x74/0x94
 [] vfs_ioctl+0x1d/0x39
 [] do_vfs_ioctl+0x32d/0x3e2
 [] SyS_ioctl+0x57/0x83
 [] ? do_page_fault+0xe/0x10
 [] system_call_fastpath+0x16/0x1b

It is because we returned the error number if the reference of the root was 0
when doing space relocation. It was not right here, because though the root
was dead(refs == 0), but the space it held still need be relocated, or we
could not remove the block group. So in this case, we should return the root
no matter it is dead or not.

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

Btrfs: kill delay_iput arg to the wait_ordered functions

2013-09-21T15:05:27+00:00

This is a left over of how we used to wait for ordered extents, which was to
grab the inode and then run filemap flush on it.  However if we have an ordered
extent then we already are holding a ref on the inode, and we just use
btrfs_start_ordered_extent anyway, so there is no reason to have an extra ref on
the inode to start work on the ordered extent.  Thanks,

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

Btrfs: fixup error handling in btrfs_reloc_cow

2013-09-21T14:58:54+00:00

If we failed to actually allocate the correct size of the extent to relocate we
will end up in an infinite loop because we won't return an error, we'll just
move on to the next extent.  So fix this up by returning an error, and then fix
all the callers to return an error up the stack rather than BUG_ON()'ing.
Thanks,

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

Btrf: cleanup: don't check for root_refs == 0 twice

2013-09-01T12:16:29+00:00

btrfs_read_fs_root_no_name() already checks if btrfs_root_refs()
is zero and returns ENOENT in this case. There is no need to do
it again in three more places.

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

Btrfs: Remove superfluous casts from u64 to unsigned long long

2013-09-01T12:16:08+00:00

u64 is "unsigned long long" on all architectures now, so there's no need to
cast it when formatting it using the "ll" length modifier.

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

Btrfs: change how we queue blocks for backref checking

2013-09-01T12:04:41+00:00

Previously we only added blocks to the list to have their backrefs checked if
the level of the block is right above the one we are searching for.  This is
because we want to make sure we don't add the entire path up to the root to the
lists to make sure we process things one at a time.  This assumes that if any
blocks in the path to the root are going to be not checked (shared in other
words) then they will be in the level right above the current block on up.  This
isn't quite right though since we can have blocks higher up the list that are
shared because they are attached to a reloc root.  But we won't add this block
to be checked and then later on we will BUG_ON(!upper->checked).  So instead
keep track of wether or not we've queued a block to be checked in this current
search, and if we haven't go ahead and queue it to be checked.  This patch fixed
the panic I was seeing where we BUG_ON(!upper->checked).  Thanks,

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