On Mon, Sep 7, 2020 at 8: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? When you have snapshots, you initially share all the same blocks. However, as you continue to make changes, fewer of the blocks are shared as new blocks are allocated for new changes. This is also true for metadata, except that this situation results in the filesystem making new instances of the metadata for most of its files. However, because you have snapshots, the old instances cannot be deleted either. Thus, you wind up with essentially a new copy of the filesystem metadata. This is amplified as you take more snapshots. This is the *expensive* part of snapshots and the part that people don't necessarily realize: when you take a snapshot, you're asking for the preservation of the entire filesystem tree, with all its data. If you take a snapshot, then change the atimes of all the files, take a snapshot again, then change the atimes again, you wind up having two whole unshared instances of the filesystem snapshotted. It's essentially the worst case scenario for filesystem metadata. Of course, this is cheap to *make*, but expensive to *keep* as you run out of space due to just having so many unique copies of filesystem metadata. This is why it's often recommended that atimes are switched off on parts of the filesystem you wish to aggressively snapshot. For example, most of the time you don't really care about atimes for /usr and /etc, so you can turn atimes off for that, while leaving it on for /var and /home. Now, we are not setting up snapshotting automatically in Fedora like openSUSE does, so there's not as much pressure to deal with it now. But if we make a straightforward way for people to set up snapshotting, then part of that strategy needs to include dealing with that problem. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
