Skip to content

RFC Btrfs: speed up fstrim

Li Zefan linux-btrfs 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest3 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3Btrfs: allow future use of type field of struct btrfs_free_space_entryfs/btrfs/ctree.h fs/btrfs/free-space-cache.c+4 -40 replies
2/3Btrfs: speed up fstrimfs/btrfs/extent-tree.c fs/btrfs/free-space-cache.c fs/btrfs/free-space-cache.h +1 more+63 -270 replies
3/3Btrfs: save trimmed flag onto diskfs/btrfs/ctree.h fs/btrfs/free-space-cache.c+17 -30 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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 trimmed

To 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 trimmed

Because 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