diff options
author | Miao Xie <miaox@cn.fujitsu.com> | 2014-06-19 10:42:50 +0800 |
---|---|---|
committer | Chris Mason <clm@fb.com> | 2014-06-19 14:20:54 -0700 |
commit | e570fd27f2c5d7eac3876bccf99e9838d7f911a3 (patch) | |
tree | 3d73f4d8a2700fd441be0abe36cf7174bfb84c56 /include/sound | |
parent | 5349d6c3ffead27d693fdac21270541fa95ef33d (diff) | |
download | op-kernel-dev-e570fd27f2c5d7eac3876bccf99e9838d7f911a3.zip op-kernel-dev-e570fd27f2c5d7eac3876bccf99e9838d7f911a3.tar.gz |
Btrfs: fix broken free space cache after the system crashed
When we mounted the filesystem after the crash, we got the following
message:
BTRFS error (device xxx): block group xxxx has wrong amount of free space
BTRFS error (device xxx): failed to load free space cache for block group xxx
It is because we didn't update the metadata of the allocated space (in extent
tree) until the file data was written into the disk. During this time, there was
no information about the allocated spaces in either the extent tree nor the
free space cache. when we wrote out the free space cache at this time (commit
transaction), those spaces were lost. In fact, only the free space that is
used to store the file data had this problem, the others didn't because
the metadata of them is updated in the same transaction context.
There are many methods which can fix the above problem
- track the allocated space, and write it out when we write out the free
space cache
- account the size of the allocated space that is used to store the file
data, if the size is not zero, don't write out the free space cache.
The first one is complex and may make the performance drop down.
This patch chose the second method, we use a per-block-group variant to
account the size of that allocated space. Besides that, we also introduce
a per-block-group read-write semaphore to avoid the race between
the allocation and the free space cache write out.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'include/sound')
0 files changed, 0 insertions, 0 deletions