Hi Gionatan. On Mon, Jan 13, 2020 at 11:22:51AM +0100, Gionatan Danti wrote: > Hi all, > as RHEL/CentOS 8 finally ships with XFS reflink enabled, I was thinking on > how to put that very useful feature to good use. Doing that, I noticed how > there is a significant overlap between XFS CoW (via reflink) and dm-thin CoW > (via LVM thin volumes). > > I am fully aware that they are far from identical, both in use and scope: > ThinLVM is used to create multiple volumes from a single pool, with > volume-level atomic snapshot; on the other hand, XFS CoW works inside a > single volume and with file-level atomic snapshot. > > Still, in at least one use case they are quite similar: single-volume > storage of virtual machine files, with vdisk-level snapshot. So lets say I > have a single big volume for storing virtual disk image file, and using XFS > reflink to take atomic, per file snapshot via a simple "cp --reflink > vdisk.img vdisk_snap.img". > > How do you feel about using reflink for such a purpose? Is the right tool > for the job? Or do you think a "classic" approach with dmthin and lvm > snapshot should be preferred? On top of my head, I can thin about the > following pros and cons when using reflink vs thin lvm: > > PRO: > - xfs reflink works at 4k granularity; > - significantly simpler setup and fs expansion, especially when staked > devices (ie: vdo) are employed. > > CONS: > - xfs reflink works at 4k granularity, leading to added fragmentation > (albeit mitigated by speculative preallocation?); > - no filesystem-wide atomic snapshot (ie: various vdisk files are reflinked > one-by-one, at small but different times). > > Side note: I am aware of the fact that a snapshot taken without guest > quiescing is akin to a crashed guest, but lets ignore that for the moment. > First of all, I think there is no 'right' answer, but instead, use what best fit you and your environment. As you mentioned, there are PROs and CONS for each different solution. I use XFS reflink to CoW my Virtual Machines I use for testing. As I know many others do the same, and it works very well, but as you said. It is file-based disk images, opposed to volume-based disk images, used by DM and LVM.man. About your concern regarding fragmentation... The granularity is not really 4k, as it really depends on the extent sizes. Well, yes, the fundamental granularity is block size, but we basically never allocate a single block... Also, you can control it by using extent size hints, which will help reduce the fragmentation you are concerned about. Check 'extsize' and 'cowextsize' arguments for mkfs.xfs and xfs_io. Cheers -- Carlos
