diff options
author | Li Zefan <lizf@cn.fujitsu.com> | 2011-12-29 14:47:27 +0800 |
---|---|---|
committer | Li Zefan <lizf@cn.fujitsu.com> | 2012-01-11 10:26:48 +0800 |
commit | 7fe1e641502616220437079258506196bc4d8cbf (patch) | |
tree | da48e34d3e826f1bfe87bf7f7743bbb0e47ab2c3 /fs/cifs/cifs_fs_sb.h | |
parent | ec9ef7a13be4dcce964c8503e8999087945e5b9e (diff) | |
download | op-kernel-dev-7fe1e641502616220437079258506196bc4d8cbf.zip op-kernel-dev-7fe1e641502616220437079258506196bc4d8cbf.tar.gz |
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/cifs/cifs_fs_sb.h')
0 files changed, 0 insertions, 0 deletions