On 2017-09-05 08:49, Henk Slager wrote:
On Tue, Sep 5, 2017 at 1:45 PM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
- You end up duplicating more data than is strictly necessary. This
is, IIRC, something like 128 KiB for a write.
FWIW< I'm pretty sure you can mitigate this first issue by running a regular
defrag on a semi-regular basis (monthly is what I would probably suggest).
No, both autodefrag and regular defrag duplicate data, so if you keep
snapshots around for weeks or months, it can eat up a significant
amount of space.
I'm not talking about data duplication due to broken reflinks, I'm
talking about data duplication due to how partial extent rewrites are
handled in BTRFS.
As a more illustrative example, suppose you've got a 256k file that has
just one extent. Such a file will require 256k of space for the data
Now rewrite from 128k to 192k. The file now technically takes up 320k,
because the region you rewrote is still allocated in the original extent.
I know that sub-extent-size reflinks are handled like this (in the above
example, if you instead use the CLONE ioctl to create a new file
reflinking that range, then delete the original, the remaining 192k of
space in the extent ends up unreferenced, but gets kept around until the
referenced region is no longer referenced (and the easiest way to ensure
this is to either rewrite the whole file, or defragment it)), and I'm
pretty sure from reading the code that mid-extent writes are handled
this way too, in which case, a full defrag can reclaim that space.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
