On Wed, 21 Aug 2019 13:42:53 -0600 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > Why do this? a) compression for home, b) encryption for home, c) home > is portable because it's a file, d) I still get btrfs snapshots > anywhere (I tend to snapshot subvolumes inside of cryptohome; but Storing Btrfs on Btrfs really feels suboptimal, good that at least you are using NOCOW; of course it still will be CoW'ed in case of snapshots. Also you are likely to run into the space wasting issue as discussed in https://www.spinics.net/lists/linux-btrfs/msg90352.html I'd strongly suggest that you look into deploying LVM Thin instead. There you can specify an arbitrary CoW chunk size, and a value such as 1MB or more will reduce management overhead and fragmentation dramatically. Or if the partition size in question is just 4GB, with today's SSD sizes, just store it as a regular LV and save on quite a bit of complexity and brittleness. > I could "snapshot" outside of it by reflink copying the backing file. Pretty sure "cp -a is not atomic, so beware, you cannot safely do this while the /home is open and mounted. On the other hand if you keep this file inside a subvolume and then snapshot it, then it is safe(r). > sysroot mkfs options: -dsingle -msingle This is asking for trouble, even if you said you power-cut it constantly, there is little reason to run with "single" metadata, not even on SSDs where some insinuate that "DUP" is always magically 100% deduped internally by the SSD during writes at speeds of 600-2500 MB/sec; even though we can't see the internals and SSD firmware is proprietary to reliably confirm or deny, this seems very unlikely, and more importantly there are other places where one (and in your case the only) copy of metadata might get corrupted: RAM, storage controller, cabling. Even a sudden poweroff has more chances to finally do its thing when there's no possible "other copy of metadata" to refer to, and the broken one is all you get. -- With respect, Roman
