summaryrefslogtreecommitdiff
path: root/fs/Makefile
diff options
context:
space:
mode:
authorLi Zefan <lizf@cn.fujitsu.com>2011-12-29 14:47:27 +0800
committerLi Zefan <lizf@cn.fujitsu.com>2012-01-11 10:26:48 +0800
commit7fe1e641502616220437079258506196bc4d8cbf (patch)
treeda48e34d3e826f1bfe87bf7f7743bbb0e47ab2c3 /fs/Makefile
parentec9ef7a13be4dcce964c8503e8999087945e5b9e (diff)
downloadlinux-3.10-7fe1e641502616220437079258506196bc4d8cbf.tar.gz
linux-3.10-7fe1e641502616220437079258506196bc4d8cbf.tar.bz2
linux-3.10-7fe1e641502616220437079258506196bc4d8cbf.zip
Btrfs: rewrite btrfs_trim_block_group()
There are various bugs in block group trimming: - It may trim from offset smaller than user-specified offset. - It may trim beyond user-specified range. - It may leak free space for extents smaller than specified minlen. - It may truncate the last trimmed extent thus leak free space. - With mixed extents+bitmaps, some extents may not be trimmed. - With mixed extents+bitmaps, some bitmaps may not be trimmed (even none will be trimmed). Even for those trimmed, not all the free space in the bitmaps will be trimmed. I rewrite btrfs_trim_block_group() and break it into two functions. One is to trim extents only, and the other is to trim bitmaps only. Before patching: # fstrim -v /mnt/ /mnt/: 1496465408 bytes were trimmed After patching: # fstrim -v /mnt/ /mnt/: 2193768448 bytes were trimmed And this matches the total free space: # btrfs fi df /mnt Data: total=3.58GB, used=1.79GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=205.12MB, used=97.14MB Metadata: total=8.00MB, used=0.00 Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Diffstat (limited to 'fs/Makefile')
0 files changed, 0 insertions, 0 deletions