summaryrefslogtreecommitdiff
path: root/fs/fuse/fuse_i.h
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-11-14 13:52:14 -0500
committerChris Mason <chris.mason@oracle.com>2011-11-20 07:42:16 -0500
commit291c7d2f577428f896daa5002e784959328a80aa (patch)
treee18fdbc7bd0d8764444615a8efb1a3f74386204a /fs/fuse/fuse_i.h
parent5bb1468238e20b15921909e9f9601e945f03bac7 (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 'fs/fuse/fuse_i.h')
0 files changed, 0 insertions, 0 deletions