RFC Btrfs: speed up fstrim
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | Btrfs: allow future use of type field of struct btrfs_free_space_entryfs/ fs/ | +4 | 0 replies | |
| 2/3 | Btrfs: speed up fstrimfs/ fs/ fs/ +1 more | +63 | 0 replies | |
| 3/3 | Btrfs: save trimmed flag onto diskfs/ fs/ | +17 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC][PATCH 0/3] Btrfs: speed up fstrim
(This patchset is not for merge or review, except the first patch)
By remembering which areas have been trimmed, we can speed up fstrim significantly.
# fstrim -v /mnt/
/mnt/: 152772608 bytes were trimmed
# fstrim -v /mnt/
/mnt/: 0 bytes were trimmedTo implement this, after a free space item has been trimmed, we mark it as trimmed before inserting it into free space cache.
(*)If we want to speed up the first fstrim after mounting the filesystem, we have to save the trimmed flag to disk, which will break backward compatibility, but only 3.2-rcX kernels will be affected.
That is, if you use fstrim in newest kernel with this patchset applied, and then you mount the fs in a 3.2-rcX kernel, you may trigger a BUG_ON() in __load_free_space_cache() sooner or later.
So, is this acceptable?
# fstrim -v /mnt/
/mnt/: 267714560 bytes were trimmed
# fstrim -v /mnt/
/mnt/: 0 bytes were trimmed
# sync
# umount /mnt
# !mount
# fstrim -v /mnt/
/mnt/: 152240128 bytes were trimmedBecause caches for block groups smaller than 100M will not be written to disk, we'll still have to trim them.
*See this thread for a user request for this feature:
https://lkml.org/lkml/2011/12/1/24