On Wed, Aug 21, 2019 at 2:12 PM Roman Mamedov <rm@xxxxxxxxxxx> wrote: > > 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, Yes, although not having native encryption on Btrfs is also suboptimal. It leaves separate file system on LUKS for /home. >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 Interesting problem. I think it can mostly be worked around by snapshoting the "upper" (plaintext) file system subvolumes, rather than the ciphertext backing file. > 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. Yes on paper LVM thinp is well suited for this. I used to use it quite a lot for throw away VMs, it's not directly supported by virt-manager but it is possible to add a thinLV using virsh. The thing is, for mortal users, it's more complicated even than LVM - conceptually and should any repairs be needed. I'm looking for something simpler that doesn't depend on LVM. > > sysroot mkfs options: -dsingle -msingle > > This is asking for trouble, even if you said you power-cut it constantly, In any case, if the hardware is working correctly, the file system is always consistent regardless of how many copies of metadata there are. I'm not sure what this gets me even hypothetically speaking, setting aside the upstream default is single for all SSDs. The filesystem definitely needs one copy committed to stable media, two copies doesn't improve the chances of commitment to stable media. Two copies is insurance against subsequent corruption. There's no such thing as torn or redirected writes with SSDs. If the first committed copy is corrupt but the second isn't, true Btrfs automatically recovers and repairs the bad copy. But I don't see how it improves the chance of data or metadata getting onto stable media. If anything, the slight additional latency of writing out a 2nd copy, delays writing the super block that points to the new tree roots. So improves handling for corruption but maybe increases the chance of an automatic rollback to an older tree at next mount? -- Chris Murphy
