On Mon, Sep 7, 2020 at 6:30 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy <lists(a)colorremedies.com> wrote:
>
> But if you've got a snapshot once per day, times ten days, and this kind of
aggressive search function touching every file? Maybe an extra 1-2G of metadata being
pinned
I don't follow. If you have one master copy and 10 snapshots, and you change the
metadata on the master copy, why would it generate more metadata (than when having a
single snapshot)? All those snapshots can share the same metadata block (provided the file
wasn't changed in the meantime) and just the master copy would get a new metadata
block. So it should be the same amount of newly written blocks, regardless of how many
snapshots you have. What am I missing?
Take the case of no snapshots, and also I'll just use "blocks" to
refer to both metadata and data extents.
The normal "modify something" pattern for copy-on-write is to write
updated blocks into free space. It's never an overwrite. Even deleting
a file requires some free space to write blocks indicating the file's
deletion. Only once the new blocks are committed to stable media, are
stale blocks deallocated (turned into free space). The resulting write
pattern is: write changes into free space -> free space is reduced ->
delay -> remove references to the stale blocks -> free space
increases. If it's just atime updates happening, the net change in
used space is zero.
Now, let's snapshot. The effect of a snapshot on a copy-on-write file
system is that the "stale" blocks are preserved. They aren't
deallocated. This is why Btrfs snapshots are cheap. The snapshot
effectively prevents the deallocation and clean up steps. Since
there's no deallocation step, free space does not go up. The net
change in used space goes up upon metadata updates following the
snapshot. If I take no further snapshots, this is just a one time hit.
Subsequent changes resume the normal pattern: write
new->delay->deallocate stale = no net change. But upon snapshotting
again, I pin that subvolume's state at that moment in time.
--
Chris Murphy