diff options
author | Josef Bacik <josef@redhat.com> | 2011-11-14 13:52:14 -0500 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2011-11-20 07:42:16 -0500 |
commit | 291c7d2f577428f896daa5002e784959328a80aa (patch) | |
tree | e18fdbc7bd0d8764444615a8efb1a3f74386204a /Kbuild | |
parent | 5bb1468238e20b15921909e9f9601e945f03bac7 (diff) |
Btrfs: wait on caching if we're loading the free space cache
We've been hitting panics when running xfstest 13 in a loop for long periods of
time. And actually this problem has always existed so we've been hitting these
things randomly for a while. Basically what happens is we get a thread coming
into the allocator and reading the space cache off of disk and adding the
entries to the free space cache as we go. Then we get another thread that comes
in and tries to allocate from that block group. Since block_group->cached !=
BTRFS_CACHE_NO it goes ahead and tries to do the allocation. We do this because
if we're doing the old slow way of caching we don't want to hold people up and
wait for everything to finish. The problem with this is we could end up
discarding the space cache at some arbitrary point in the future, which means we
could very well end up allocating space that is either bad, or when the real
caching happens it could end up thinking the space isn't in use when it really
is and cause all sorts of other problems.
The solution is to add a new flag to indicate we are loading the free space
cache from disk, and always try to cache the block group if cache->cached !=
BTRFS_CACHE_FINISHED. That way if we are loading the space cache anybody else
who tries to allocate from the block group will have to wait until it's finished
to make sure it completes successfully. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions