On Fri, 2019-03-08 at 07:20 -0500, Austin S. Hemmelgarn wrote: > On 2019-03-07 15:07, Zygo Blaxell wrote: > > Legacy POSIX doesn't have the hole-punching concept, so legacy > > tools won't do it; however, people add features to GNU tools all > > the > > time, so it's hard to be 100% sure without downloading the code and > > reading/auditing/scanning it. I'm 99% sure cp and tar are OK. > > > They are, the only things they do with sparse files are creating new > ones from scratch using the standard seek then write method. The > same > is true of a vast majority of applications as well.
Thanks for your confirmation. > The stuff most > people would have to worry about largely comes down to: > > * VM software. Some hypervisors such as QEMU can be configured to > translate discard commands issued against the emulated block devices > to > fallocate calls to punch holes in the VM disk image file (and QEMU > can > be configured to translate block writes of null bytes to this too), > though I know of none that do this by default. > * Database software. This is what stuff like punching holes > originated > for, so it's obviously a potential source of this issue. > * FUSE filesystem drivers. Most of them that support the required > fallocate flag to punch holes pass it down directly. Some make use > of > it themselves too. > * Userspace distributed storage systems. Stuff like Ceph or > Gluster. > Same arguments as above for FUSE filesystem drivers. These do at least not affect me personally, though only because I didn't use compress, where I use qemu (which I have configured to pass on the TRIMs). > > 'btrfs' (the command-line utility) doesn't do these operations as > > far > > as I can tell. The kernel only does these when requested by > > applications. > The receive command will issue clone operations if the sent > subvolume > requires it to get the correct block layout, so there is a 'regular' > BTRFS operation that can in theory set things up such that the > required > patterns are more likely to happen. As long as snapshoting itself doesn't create the issue, I should be still safe at least on my master disks (which were always only the source or send/receive), which I'll now compare to the backup disks Thanks, Chris.
