V11 XFS Supported OS

[PTide]

Now I just have to convince QA if the above!

The success of that mission also depends on how long Leap 15.3 will be alive : )

QA doesn't really like to test stuff that is soon to be decomissioned. The current Leap average of 1.5 years doesn't look very promising to me, especially if we compare that to our release cycles. It simply feels like Leap will always be either too early or too late.

[Regnor]

Thanks @tsightler for looking at openSUSE. For me it's the perfect alternative to CentOS, except for the short lifecycle. And as you say the migration to SLES is a big plus, if needed. Good luck with the QA team

@PTide You're right and I don't know how to solve this easily.
Would users have to stay on a EOL version till Veeam validates the next release? Or does the offical Veeam support end as soon as a openSUSE release goes EOL?
I wished the lifecycle was a bit longer or they offered a long term support for certain releases.

[tsightler]

QA doesn't really like to test stuff that is soon to be decomissioned. The current Leap average of 1.5 years doesn't look very promising to me, especially if we compare that to our release cycles. It simply feels like Leap will always be either too early or too late.

But this isn't different than how CentOS worked, and we supported it just fine. Basically, Leap 15.3 is supported for 18 months because, after that, Leap users will be expected to move to Leap 15.4. We'll have to support SLES 15.4 anyway and, since they are basically identical, Leap 15.4 should just be automatic, like it previously was with CentOS. Of course, that's just my opinion at this point.

To be completely clear, CentOS was exactly like this (I think that was the point the article linked in one of the post above was attempting to make). With CentOS, only the most recent point release was actively supported, while, if you paid for RHEL you could pin the specific releases and stay on them longer. When RHEL 8.2 came out, CentOS 8.2 would ship some time later, but once it did, there was only CentOS 8.2 that was supported.

From my perspective, Leap 15.3 and greater are so similar to SLES, even using the very same binary packages in almost all cases, that we should consider it supported as we previously did for CentOS, which had a nearly identical lifecycle but was actually far more different.

That being said, usage also matters, and I've yet to see Leap make the leap, so to speak, to a distro commonly used across our user base. Ubuntu and Debian are both still infinitely more common, but, if there's something that replaces CentOS that's not a different RHEL based rebuild (like Rocky Linux or Alma Linux, both currently in Release Candidate) then Leap is it, and since we will definitely support SLES anyway, it feels like it's nearly automatic.

None of that means QA will agree with me though!

[dgcom]

Apologies for reviving this old thread, however my question is directly relevant to this topic:
Is Oracle Linux supported as repository with advanced XFS integration (Fast Clone)?
One of the old posts above says that it is not supported due to unbreakable kerne, however Oracle Linux is available with Red Hat compatible kernel (RHCK) kernel as well?
Asking, because I'd rather upgrade existing CentOS 7 to Oracle Linux 8 than rebuild this device...

Can someone clarify this for me, please?

[HannesK]

Hello,
and welcome to the forums. Oracle Linux with XFS fastcloning has experimental support. Please see the user guide -> system requirements and search for XFS. Same like CentOS 7 by the way... only CentOS 8.2-8.5 has full support.

I see no reason to rebuild the device.
Best regards,
Hannes

[dgcom]

Thank you for the response. I saw both links you included, however neither of them have an answer to the question I posted. The KB article has no information about any OS and the documentation link just bluntly states that support is experimental without any relevant details besides kernel version recommendation.
I am also surprised that you mention CentOS 7 - Fast Clone does not work there and actually creates a problem for repository if it is created with this support enabled.

[HannesK]

hmm, maybe there is a misunderstanding... fast clone is working on every distribution - it's an XFS feature. The distribution is technically irrelevant. For performance reasons, kernel 5.4 and newer is recommended.

It's just a matter of "full support" and "experimental support". There reason for "experimental support" is that we only test certain Linux distributions.

[dgcom]

When I deploy repository to my CentOS 7 box and enable "Use fast cloning on XFS volumes", I get a message saying that fast cloning is "disabled" on that system.
It allows me to proceed, but then synthetic backup fails when trying to create full copy.

I could not find a way to check if fast cloning is enabled or disabled, I only saw some references that:
- XFS should be version 5 (which is true in my case)
- reflinks should be enabled - this I did not find a way to check, unfortunately

I also find some reference (can't find a link right now) that reflinks require kernel module and it is only included in CentOS/Oracle 8...

Maybe there is a way to check/enable reflinks on existing XFS - if so, any advice would be welcome.

[Gostev]

You cannot enable reflink on existing XFS, you have to do it when you provision the XFS volume. Just follow the User Guide.

[dgcom]

I just did more detailed research.
It is not possible to use reflinks in CentOS 7:
- mkfs.xfs in CentOS 7 is version 4.5 and it does not have reflinks metadata option
- Reflinks is only available in kernel 4.9 and higher, current CentOS 7.9 has kernel 3.10
References:
https://bbs.archlinux.org/viewtopic.php?id=212825
https://access.redhat.com/documentation ... ide/ch-xfs
https://blogs.oracle.com/linux/post/xfs ... ng-reflink

Based on this, can someone from Veeam confirm, which RPM-based Linux distribution is supported for XFS reflinks/fast copy?
As far as I can see, CentOS 8/Oracle 8/RHEL 8 include kernel 4.18 - so, there is a good chance this would work.
Since Oracle 8 has full RHEL-compatible kernel, I do not understand why it is not included in the supported OS list...

[Gostev]

For the list of distributions supported for XFS integration, please refer to the System Requirements (Backup Repository section).

[dgcom]

Thank you for the response, but I wonder if even read my messages? I did read System Requirements and it did NOT list Oracle Linux.

Since there is no direct answer here, I presume that Veeam does not support this particular distribution.

Also, because Veeam is not checking properly that CentOS 7 does not support XFS reflinks, I now ended up with broken repository.

Can you please advise what is the best way to fix this issue? Can I delete and re-create repository without loosing incremental backups?

[dgcom]

I was able to uncheck "Use fast cloning on XFS volumes" by editing the repository. Will have to wait until Saturday for the next synthetic backup to verify if that helped.

I also plan to try and migrate to Oracle 8 - then I can test reflinks (turns out this is a correct name for the fast clone feature).
I'll report here, since Veeam, unfortunately, can't test that.

[HannesK]

I did read System Requirements and it did NOT list Oracle Linux.

distributions that are not listed have experimental support. I marked it in yellow below

I presume that Veeam does not support this particular distribution.

only experimental. but it works. I have Oracle Linux 7.9 and 8.5 running with XFS fast cloning in my lab.

reflink must be enabled during creation of the XFS file system. with modern distributions it's enabled per default. for older distributions like Oracle Linux 7.9 it has to be enabled manually (as stated in the user guide)

Can you please advise what is the best way to fix this issue? Can I delete and re-create repository without loosing incremental backups?

deleting a repository in the VBR console leaves the backup files intact. nothing gets deleted. but you cannot delete the repository as long as backup jobs are still pointing to it.

[dgcom]

I have Oracle Linux 7.9 and 8.5 running with XFS fast cloning in my lab.

I did not check Oracle 7.9 but I am absolutely sure that reflinks are not available in CentOS 7.9.
I provided references to the documentation and also tested myself:

Code: Select all

$ lsb_release -d
Description:    CentOS Linux release 7.9.2009 (Core)
$ sudo mkfs.xfs -m reflink=1 /dev/sdb1
unknown option -m reflink=1

Looking at Oracle docs, 7.9 would depend on kernel used:

Code: Select all

kernel-3.10.0-1160.el7
    Red Hat Compatible Kernel (RHCK)
kernel-uek-5.4.17-2011.6.2.el7uek
    Unbreakable Enterprise Kernel Release 6 (UEK R6) 

It might work with UEK, but that might be less compatible with Veeam than RHCK.

[dgcom]

I performed more testing by switching my test machine from CentOS 7.9 to Oracle Linux 7.9 using centos2ol.sh script.
It installs UEK by default, so I was able to create XFS with reflinks. You have to specify both crc and reflinks flags:

Code: Select all

$ sudo mkfs.xfs -m reflink=1,crc=1 /dev/sdc1
meta-data=/dev/sdc1              isize=512    agcount=4, agsize=8323008 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=33292032, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16255, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Discarding blocks...Done.

What is good, there is an easy way to VERIFY if XFS file system has reflinks enabled (this is a piece of info I was trying to find and couldn't):

Code: Select all

$ sudo xfs_db /dev/sdc1 -c version
versionnum [0xbca5+0x18a] = V5,NLINK,DIRV2,ALIGN,LOGV2,EXTFLG,SECTOR,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT,CRC,FTYPE,FINOBT,SPARSE_INODES,REFLINK

If the output of this command includes reflink - the filesystem should be fine, however it is not all.
As I mention previously, the kernel has to support it too and this is my main complain about generic "system requirements" advice from Veeam

"For other distributions, XFS integration support is experimental, with kernel version 5.4 or later recommended."

It is really lacking specifics. Oracle Linux 7.9 can be switched to RHCK which is version 3.10 and it does not support reflinks - and attempt to use filesystem with reflinks flag set on that kernel can create many issues, I saw an article from RH about this.

It would be beneficial to have more detailed requirements for experimental support of XFS advanced capabilities, for example:

• Kernel 4.9 or higher, 5.0 or higher is recommended

• xfsprogs package version 5 or higher

• File system created with flags reflink=1,crc=1

Just for the record, Oracle 7.9 with UEK:

Code: Select all

$ rpm -q xfsprogs
xfsprogs-5.4.0-1.0.1.el7.x86_64
$ uname -r
5.4.17-2136.304.4.4.el7uek.x86_64

I haven't upgraded my actual repository yet, since it will require file system to be recreated, but I am planning this work.

Hopefully, this information will help others, since it is not available from Veeam directly.

[mkretzer]

Hello,

what about Ubuntu 22.04 - did anyone do any tests already with XFS on that version?

Markus

[dgcom]

what about Ubuntu 22.04 - did anyone do any tests already with XFS on that version?

As I understand it, this is not about distro version - functionality depends on Linux kernel and xfs tools versions.
Run

Code: Select all

$ apt show xfsprogs
$ uname -r

And check, but I'd think latest Ubuntu version should be fine.

[Kim29]

I'm not sure Can I using opensuse for the linuxrepo enable XFS. The customer don't have money for buy SLES and subscription and helpcenter not mention it.

For advanced XFS integration, only the following 64-bit Linux distributions are supported:
CentOS 8.2, 8.3, and 8.41, and 8.52
Debian 10.x, and 111
RHEL 8.2, 8.3, and 8.41, and 8.52
SLES 15 SP2, and SP31
Ubuntu 18.04 LTS, 20.04 LTS, and 21.041, and 21.102

[Mildur]

Hi Jareewan

I moved your post to this topic. Please see the answers of my colleagues.
It can work, but it's not tested by us. If you face any issue, our support (and the R&D forum) will most likely not be able to help.
I would stick to a supported operating system. There are many free to choose from.

Thanks
Fabian

[Regnor]

In theory SLES and openSUSE are (binary) compatibly since openSUSE 15.3 as they share the same sources. So if SLES is supported, chances are high that it also works with openSUSE; though it doesn't change anything as it will still not officaly be supported (experimental).
If you read through this topic, I wrote about this with tsightler, but I didn't follow up as I've decided to go with Ubuntu with a longer lifecycle. Perhaps Tom can comment if there are any planned changes for v12.

[HannesK]

I can add, that we did not have any XFS issues in support so far. If you want to be on the safe side, please go with the officially supported distributions. It looks like everything works (in case official full support is not that important for you)