On 09/16/2017 07:06 AM, Kai Krakow wrote: > Am Fri, 15 Sep 2017 14:28:49 -0400 > schrieb Rich Freeman <ri...@gentoo.org>: > >> On Fri, Sep 8, 2017 at 3:16 PM, Kai Krakow <hurikha...@gmail.com> >> wrote: >>> >>> At least in btrfs there's also a caveat that the original extents >>> may not actually be split and the split extents share parts of the >>> original extent. That means, if you delete the original later, the >>> copy will occupy more space than expected until you defragment the >>> file: >> >> True, but keep in mind that this applies in general in btrfs to any >> kind of modification to a file. If you modify 1MB in the middle of a >> 10GB file on ext4 you end up it taking up 10GB of space. If you do >> the same thing in btrfs you'll probably end up with the file taking up >> 10.001GB. Since btrfs doesn't overwrite files in-place it will >> typically allocate a new extent for the additional 1MB, and the >> original content at that position within the file is still on disk in >> the original extent. It works a bit like a log-based filesystem in >> this regard (which is also effectively copy on write). > > Good point, this makes sense. I never thought about that. > > But I guess that btrfs doesn't use 10G sized extents? And I also guess, > this is where autodefrag jumps in.
According to btrfs-filesystem(8), defragmentation breaks reflinks, in all but a few old kernel versions where I guess they tried to fix the problem and apparently failed. This really makes much of what btrfs does altogether pointless if you ever defragment manually or have autodefrag enabled. Deduplication is broken for the same reason.
signature.asc
Description: OpenPGP digital signature
