| commit | 206b329c9cc70b9a3305177064dee0e209d224dd | |
| author | Josef Bacik <jbacik@fb.com> | |
| Thu, 18 Sep 2014 15:27:17 +0000 (18 11:27 -0400) | ||
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
| Thu, 30 Oct 2014 16:40:09 +0000 (30 09:40 -0700) | ||
| tree | 73d15ea5ad0640ec0c65c45e416bd4848be7aeca | treesnapshot (tar.gz zip) |
| parent | aee223787acc8ad97d72a91a54f26f81375b2c38 | commitdiff |
Btrfs: don't do async reclaim during log replay
commit f6acfd50110b335c7af636cf1fc8e55319cae5fc upstream.
Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
during log replay. This is because we use fs_info->fs_root as our root for
shrinking and such. Technically we can use whatever root we want, but let's
just not allow async reclaim while we're doing log replay. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6acfd50110b335c7af636cf1fc8e55319cae5fc upstream.
Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
during log replay. This is because we use fs_info->fs_root as our root for
shrinking and such. Technically we can use whatever root we want, but let's
just not allow async reclaim while we're doing log replay. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| fs/btrfs/extent-tree.c | diffblobblamehistory |