On Wed, Apr 29, 2020 at 12:39 PM Stefanie Leisestreichler <stefanie.leisestreichler@xxxxxxxxxxxxxx> wrote: > > > > On 29.04.20 20:33, Hugo Mills wrote: > > Don't use snapshots, or don't use nodatacow. > > > > Set autodefrag and don't use nodatacow would be my recommendation. > > Thanks for this smart tip. > > I guess, the same applies to a subvolume which will hold images of > virtual machines, right? For both VMs and loop mounted LUKS encrypted file systems, I use a raw file (no format). In a directory that has +C set. So all the files inherit that. If the lifecycle is short, or I need to test a virtual size device, then I use truncate to set the virtual size. It only consumes the space actually used, so often I'm in the habit of just 'truncate -s 1T'. Often the file system is Btrfs. Yes it gets fragmented. And since it's a short lifecycle I don't care much. The initial performance is good, maybe better than fallocate. If the lifecycle is longer, then I use fallocate. This tends to not fragment much at all, even with Btrfs inside. And if I have some hybrid need, where the file system might need to get better, but I don't want to give up the space right away, I combine: truncate -s 100G file fallocate -l 10G file If I don't use +C for the file, there are better and worse choices for the "guest" file system in the file. Btrfs fragments less than a journaled file system. I don't know the exact mechanism, but I suspect the constant journal overwrites in the guest, turn into COW on Btrfs which is why the raw file becomes so terribly fragmented - way worse than if it were Btrfs. I think you'd need a benchmark of some kind to see what the latencies are due to fragments, and it might depend significantly between single and multi-queue devices. -- Chris Murphy
