Btrfs: fix broken free space cache after the system crashed
authorMiao Xie <miaox@cn.fujitsu.com>
Thu, 19 Jun 2014 02:42:50 +0000 (10:42 +0800)
committerChris Mason <clm@fb.com>
Thu, 19 Jun 2014 21:20:54 +0000 (14:20 -0700)
commite570fd27f2c5d7eac3876bccf99e9838d7f911a3
tree3d73f4d8a2700fd441be0abe36cf7174bfb84c56
parent5349d6c3ffead27d693fdac21270541fa95ef33d
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>
fs/btrfs/ctree.h
fs/btrfs/extent-tree.c
fs/btrfs/free-space-cache.c
fs/btrfs/inode.c