https://bugzilla.suse.com/show_bug.cgi?id=1222313 https://bugzilla.suse.com/show_bug.cgi?id=1222313#c11 Wenruo Qu <wqu@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.niederwanger@suse.com | |, wqu@suse.com Flags| |needinfo?(felix.niederwange | |r@suse.com) --- Comment #11 from Wenruo Qu <wqu@suse.com> --- If you have some random IO workload, it's very possible that btrfs bookend extents are causing the problem. Furthermore, if you have truncated files (which is previously very large or preallocated), it can also take tons of unexpected space. Another point is, preallocation (falloc) is very btrfs unfriendly, if you have something like VM images, you'd be much better disable the snapshot of that subvolume, and set NOCOW flag for them. But since you have snapshots, the normal way to solve the problem (defrag) is not suitable as it would break the shared extents and cause extra space usage. It's recommended to delete all the unnecessary snapshots, and try "btrfs fi defrag" to see if it help (needs a sync after full defrag). Although there is a limitation on defrag that truncated files may not be that well defragged. If regular defrag (after deleting all snapshots) is not helping, you may want to try the following patches: - kernel part to enhance defrag: https://lore.kernel.org/linux-btrfs/cover.1710213625.git.wqu@suse.com/ - btrfs-progs support https://lore.kernel.org/linux-btrfs/cover.1710214834.git.wqu@suse.com/ -- You are receiving this mail because: You are on the CC list for the bug.