Hi Gionatan. On Mon, Jan 13, 2020 at 12:25:26PM +0100, Gionatan Danti wrote: > On 13/01/20 12:10, Carlos Maiolino wrote: > > 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. > > Hi Carlos, thank you for pointing me to the "cowextsize" option. From what I > can read, it default to 32 blocks x 4 KB = 128 KB, which is a very > reasonable granularity for CoW space/fragmentation tradeoff. > > On the other hand, "extsize" seems to apply only to realtime filesystem > section (which I don't plan to use), right? I should have mentioned it, my apologies. 'extsize' argument for mkfs.xfs will set the size of the blocks in the RT section. Although, the 'extsize' command in xfs_io, will set the extent size hints on any file of any xfs filesystem (or filesystem supporting FS_IOC_FSSETXATTR). Notice you can use xfs_io extsize to set the extent size hint to a directory, and all files under the directory will inherit the same extent hint. Cheers. > > Thanks. > > -- > Danti Gionatan > Supporto Tecnico > Assyoma S.r.l. - www.assyoma.it > email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx > GPG public key ID: FF5F32A8 > -- Carlos
