On Thu, Apr 23, 2020 at 6:39 AM Filipe Manana <fdmanana@xxxxxxxxx> wrote: > > On Thu, Apr 23, 2020 at 1:06 PM Marek Behun <marek.behun@xxxxxx> wrote: > > > > On Thu, 23 Apr 2020 12:51:32 +0100 > > Filipe Manana <fdmanana@xxxxxxxxx> wrote: > > > > > There's nothing in btrfs that converts a sequence of zeroes > > > automatically to a hole. > > > > > > It always has to be done by user space, either by writes that leave > > > holes intentionally (e.g. create file, write 64K to offset 0, write 4K > > > to offset 128, leaves a hole from range 64K to 128K) or by hole > > > punching through fallocate(). > > > > Thanks for this information. If you ever come to Prague, let me know, > > we can have a beer :D > > Noted! (Through it will be a long while until travel is allowed and safe) > > Another case I forgot is a hole created by truncation - truncate a > file to a larger size, then you get a hole for the range that goes > from the old file size to the new file size. I recently discovered the benefit of using both truncate and partially fallocating a VM backing file. I start with truncate so I can set a typical device size for the guest's view, which I don't have the local space if I were to fallocate. e.g. 100G local, but do truncate -s 1T. Then follow that with fallocate -l 12G so that I don't end up with a massively fragmented backing file. To be clear, this backing file is set with chattr +C and never snapshot or reflinked. Btrfs initially doesn't seem to perform any different with sparse or fallocated backing files. But with aging, the sparse file can get really fragmented depending on the guest file system. Tens of thousands of extents are possible, and that does impact performance it seems. -- Chris Murphy
