V10 & XFS - all there is to know (?)

[jasonede]

What's the news on other releases with XFS and relinks?

I see that XFS and relink is supported in RedHat 8 and Centos 8 and can't find reference to it being experimental in the documentation.

[ferrus]

Working great here on Ubuntu 20.04.
(I know it's not supported yet - but it's the third data copy, at a DR site, and 18:04 just wouldn't install).

Just tested with modest amounts of data so far, will try and scale it up to around 30TB soon, to see how it compares with ReFS.

[zyrex]

@ferrus, could you maybe tell me about your process? I'm running 19.10 and can not get it to work..

[ferrus]

As far as I can tell, there's only two steps to enable it.
Firstly, using the reflink argument during the initial format:

Code: Select all

mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sda1

from https://helpcenter.veeam.com/docs/backu ... ml?ver=100

And enabling XFS Fast Clone on the repository, when you add it to Veeam:
(I actually missed this step, because it's automatic with ReFS)


from https://lnx.gable.it/2020/03/01/addicti ... -on-veeam/

There are additional firewall steps on the page above (albeit for CentOS). I didn't have to do those, but it may be worth looking at on your installation.

[tsightler]

@ferrus, could you maybe tell me about your process? I'm running 19.10 and can not get it to work..

@zyrex Did you run new full backups after you enabled XFS block clone in the settings? Backups created prior to this setting cannot be used for block cloning because they'll have been created without align blocks. Otherwise, the overall process is very straightforward, make sure the volume has reflink/crc enabled, and make sure the repository setting is enabled, there are no additional requirements and I'd strongly suggest contacting support if you are still having issues.

[tsightler]

What's the news on other releases with XFS and relinks?

I see that XFS and relink is supported in RedHat 8 and Centos 8 and can't find reference to it being experimental in the documentation.

You can find the reference in the documentation here:

https://helpcenter.veeam.com/docs/backu ... =100#linux

The specific quote is:

Supported distributions: Ubuntu 18.0.4 or later. For other distributions, Fast Clone support is experimental.

Basically experimental means that QA has not fully tested it but we don't see any reason it would not work and support will still work with you if you use it. I've been personally hammering block clone on CentOS 8 for a few months now and I've seen no critical issues, just a few minor things with memory allocation during peak load. I still think Ubuntu 20.04 will be my preferred choice due to a much newer kernel with all the XFS enhancement, but, at least so far, CentOS 8 seems pretty solid for me. Only time and scale will actually tell though.

[zyrex]

@zyrex Did you run new full backups after you unabled XFS block clone in the settings? Backups created prior to this setting cannot be used for block cloning because they'll have been created without align blocks. Otherwise, the overall process is very straightforward, make sure the volume has reflink/crc enabled, and make sure the repository setting is enabled, there are no additional requirements and I'd strongly suggest contacting support if you are still having issues.

Thanks, that's a good point - I haven't ran a new full backup after enabling the XFS fast clone on the repository... I guess that's the next step I've doublechecked that reflink/crc is enabled on the volume so that should be fine now.

[DonZoomik]

I had alignment option enabled while creating repo about a month ago with v9.5 (I knew that XFS support was coming). Does this help retroactively?

[c.schulzejn]

What are the Pros and Cons of xfs+nfs vs. ReFS+iscsi?

[Gostev]

There are no differences from Veeam perspective.

[tsightler]

What are the Pros and Cons of xfs+nfs vs. ReFS+iscsi?

I'd say this question is a little confusing because of the mix of NFS and iSCSI. Both XFS and ReFS are filesystems for block devices (i.e. disks) which can be presented via any block device protocol (SATA, SAS, RAID, FC, iSCSI, etc). NFS is a network filesystem and is really unreleated to XFS, although XFS could be a backing device for an NFS share, as can pretty much any filesystem. If you want to use block clone the question is probably more accurately what are the pros and cons of XFS+iSCSI vs ReFS+iSCSI.

With that question, as @Gostev notes, there's little functional difference from the Veeam perspective between these two. From the user perspective the obvious differences are Windows vs Linux, and the fact that ReFS block clone support has been out for quite a while, so we know it mostly works OK, although there are cases where it's not perfectly stable, while XFS block clone support is brand new and lightly deployed in production so, while we don't expect issues, we also don't have a lot of real world history on it's overall stability for production scale environments as that only comes with time.

[Gostev]

Ah, my bad - I missed the NFS part. Tom is right!

[Ejdesgaard]

When can we expect full support for RHEL-8 and/or CentOS-8 for xfs reflink ?

[Gostev]

This will largely depend on how many customers will adopt it under experimental support terms in the coming months, and what results do they see. We will prioritize the official support for different distros based on actual adoption rates.

[lasseoe]

Have you come across any issues with XFS & Fast Clone yet? Any reported issues on CentOS/RHEL/OEL 8 ?

[Gostev]

No, we did not have any issues reported thus far.

[pedroa]

Hi all,

I'm looking for best practices when deploying a Linux XFS with reflink enabled.

Windows ReFS has a recommendation of 1GB per 1TB of stored data, what would be in this case using XFS with Reflink?

thanks,

Pedro

[nitramd]

Hello Pedro.

I'd suggest taking a look at this post: veeam-backup-replication-f2/v10-xfs-all ... 65222.html

It may not answer your question directly but it might give you more information about XFS in general.

[soncscy]

Hi all,

I'm looking for best practices when deploying a Linux XFS with reflink enabled.

Windows ReFS has a recommendation of 1GB per 1TB of stored data, what would be in this case using XFS with Reflink?

thanks,

Pedro

Hi Pedro,

IIRC, that recommendation for ReFS is outdated and reflected only a state in time of ReFS. Nowadays, normal repository sizing should be fine. (Happy to be corrected if I'm wrong here)

But, I think XFS is still kind of new and it's harder to say what the "ideal" setup should be. My take is that assuming no XFS bugs, normal repository sizing ought be fine. I have relegated XFS to non-essential VMs for my clients just because even though it's been in the stable branch for a few distros for a few years now, I want a few more years under the belt before I 'm ready to consider it prime time.

So, size it normally, but I advise don't go 100% in on XFS just yet.

[paul.hambleton]

Is there any benefit to enabling Fast Clone if Veeam Encryption is enabled?

My assumption is that encryption means there are no common blocks therefore no point using Fast Clone.

[DerOest]

Is there any benefit to enabling Fast Clone if Veeam Encryption is enabled?

My assumption is that encryption means there are no common blocks therefore no point using Fast Clone.

Veeam can look inside/"behind" the encryption - it knows which metadata/datablocks inside the encrypted backup-files correspond to which source-datablocks.
Therefor Fast Clone works just perfectly fine with encrypted backups!

> encryption means there are no common blocks
That is the whole point of Fast Clone - instead of copying to new blocks, just reuse existing blocks - make as few "no common blocks" as possible. As above, it works because Veeam itself performs the encryption and knows what is what.

[crackocain]

Hello

What is the Veeam best practise block size for XFS? As you know ReFS best practise block size is 64K.

[tsightler]

Unless something has changed very recently the XFS on-disk format itself supports block sizes up to 64K, but there is a huge caveat, the actual XFS implementation on Linux limits the maximum supported block size = kernel page size (documented in the mkfs.xfs man page for the -b option). On x86/amd64 architectures the Linux kernel page size is 4K, so the effective maximum supported block size for XFS is 4K and is the recommend best practice as well as what most systems will use by default. For the newest distros with latest xfs-progs packages (RHEL8, Ubuntu 20.04) the mkfs.xfs command also sets the crc=1 and reflink=1 options by default as well so they will "just work" with the correct settings out-of-the-box, but you can always pass them specifically if you just want to be sure.

[kspare]

Just curious, now that some people are 6 months into unbuntu and xfs, is there a performance gain to be had? We have a customer running a windows 2016 refs/iscsi proxy/repo and it works ok. But as we setup other customers it would be nice not to have to buy that windows license....

So is unbuntu/iscsi/xfs the way to go now?

[mweissen13]

After 4 months of use I can tell that XFS seems to fragment much less than ReFS, which translates to a better performance, especially for merges on spinning disks, in the long term. In my book it seems to be pretty stable too. On flash storage the difference will probably be negligible.

[ferrus]

Just curious, now that some people are 6 months into unbuntu and xfs, is there a performance gain to be had? We have a customer running a windows 2016 refs/iscsi proxy/repo and it works ok. But as we setup other customers it would be nice not to have to buy that windows license....

So is unbuntu/iscsi/xfs the way to go now?

It's hard to compare performance for us.
The figures we have actually show XFS to be better - but the sites where we use ReFS/XFS, have different hardware and data sets, making the comparison difficult.
I can certainly say that we haven't had any performance issues with XFS, and the data rates and fast clones we have with it are similar to what we'd expect with ReFS.

What has been a huge difference for us, is the stability.

It took years for ReFS to become stable with acceptable performance, necessitating several rebuilds and some data loss.
XFS/Reflink has been rock solid for us, since it's first introduction to Veeam. And we started using it a few weeks after release.

We still only have it at our DR site - but as soon as Veeam release the touted support for physical Linux proxies/Direct SAN support, I'll certainly rebuild all of our Windows Proxy+Repo servers to use it.
The saving of Windows licenses makes it an even better option. I also like having the backup data on a different OS platform, from a security point a view.

[crackocain]

Hello

I want to ask Oracle RMAN Plugin or SAP Backint could use XFS Reflink?

[Gostev]

No, they can't. Fast cloning is available for image-level backups only, which plug-in backups are not - they are streaming backups.

[crackocain]

Hello everyone

I want to ask what is the Veeam best compression settings and storage optimization settings with XFS reflink.

Veeam compressed and write blocks with defaults, Optimal compression and Local Target (1MB chunks)
So Veeam analyze 1MB and compressed 512K (if %50 compression)
When compression enable blocks alignment always changing.
I wonder if no compression setting enabled gain better block clone ratio? Yes compression is good with short retention but when the purpose is 5 year backup retention with same XFS repository, i think better block clone ratio more important. Am i think right way this subject?

Thank you.

[tsightler]

I believe you might not be thinking of it correctly. When Veeam clones blocks, it is doing so post-compression. If you have 1000 unchanged blocks in the chain when a synthetic full is created, it doesn't matter if they are compressed or uncompressed, Veeam will clone the space used by those 1000 blocks. If the block was written uncompressed, it would clone the full 1MB of data, if the block was compressed, only the space used by the compressed size of the block would need to be cloned to the new block.