On Mon, Sep 7, 2020 at 6:30 AM Kamil Paral <kparal@xxxxxxxxxx> wrote: > > On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
