XFS "barrier/nobarrier" mount options have been completely deprecated starting from SLES15 SP2

SUSE Linux Enterprise Server for SAP Applications 15 SP2
SUSE Linux Enterprise Server for SAP Applications 15 SP1
SUSE Linux Enterprise Server for SAP Applications 15 SP0
SUSE Linux Enterprise Server for SAP Applications 12 SP5
SUSE Linux Enterprise Server for SAP Applications 12 SP4

SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server 12 SP4 LTSS
 

On SLES15 SP2 (kernel 5.3.18*), the XFS filesystems can not be mounted when using "nobarrier" or "barrier" options, throwing the following error:

terminus:~ # mount -o nobarrier /dev/vdb1  /hana
mount: /hana: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error.

terminus:~ # mount -o barrier /dev/vdb1 /hana
mount: /hana: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error.

The reason is given on dmesg logs:

[   82.226379] XFS (vdb1): unknown mount option [nobarrier].
[   91.457530] XFS (vdb1): unknown mount option [barrier].

While on SLES12 SP4 LTSS, SLES12 SP5 and SLES15 SP1 the XFS filesystems can be mounted using "barrier/nobarrier" options but they are being ignored, as also referenced on dmesg logs:

[4936664.652743] XFS (sdb): nobarrier option is deprecated, ignoring.
[4936671.111094] XFS (sdb): barrier option is deprecated, ignoring.

Please avoid using "barrier/nobarrier" mount options for XFS filesystem starting with SLES15 SP2, as they have been completely removed before kernel 5.3.18. Barriers are now enabled by default on XFS. The upstream kernel has completely removed those particular options parsing since commit 1c02d502c208 ("xfs: remove deprecated barrier/nobarrier mount") which landed in upstream kernel v4.19.

While on SLES12 SP4 LTSS, SLES12 SP5, SLES 15 SP0 (no support pack) and SLES15 SP1 (kernel 4.12.14*) it is possible to mount the XFS filesystems with "barrier/nobarrier" options, however those options are being ignored. Before XFS completely deprecated those options, there was an initial period of two years where those options were being still recognized but ignored.

As "barrier/nobarrier" options on XFS has been completely removed on SLES15 SP2, those options are being rejected as unrecognized and the mount command will fail. The following error during mount, is the generic error that mount utility will print upon returning -EINVAL from the mount syscall (which unfortunately can be the result of quite a lot of different reasons, see mount (2) man page for more details):

terminus:~ # mount -o nobarrier /dev/vdb1  /hana
mount: /hana: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error.

terminus:~ # mount -o barrier /dev/vdb1  /hana
mount: /hana: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error.

On SLES15 SP0, SLES15 SP1, SLES12 SP4 LTSS, SLES12 SP5, "barrier/nobarrier" options are still recognizable but they have no effect. This change has been introduced with commit 4cf4573d899c ("xfs: deprecate barrier/nobarrier mount option") which landed in kernel v4.10 upstream.

This change is also referenced on xfs (5) man page:

barrier|nobarrier

Note: This option has been deprecated as of kernel v4.10; in that version, integrity  operations are  always  performed and the mount option is ignored. These mount options will be removed no earlier than kernel v4.15. 

Enables/disables the use of block layer write barriers for writes into the journal and for data integrity  operations. This  allows  for drive level write caching to be enabled, for devices that support write barriers.

Barriers are enabled by default.

Reported to Engineering

Some more details (not specific to XFS), regarding  paragraph "12.3: I/O Barrier Tuning" on [1]. The original text is mostly taken from commit 571640cad3fd ("ext4: enable barriers by default"), which although is still valid it is  a bit dated and may not fully reflect its purpose.

Specifically: if caches are present, barriers should never be disabled (as long as filesystem consistency is required). This is why XFS doesn't even offer the option any more, and why it's on by default on ext4. The block layer will automatically send down to the devices flushes and FUA commands when required by the filesystem, as long as the underlying block device advertises a cache. If the device doesn't advertise a cache, then the block layer will ignore those, and not dispatch any flush requests.

In case of battery-backed controllers and devices, usually those feature a cache (which is protected by the battery) but advertise no cache to the kernel, so no flushes will be send anyway (thus there would be no performance improvement in disabling barriers in any case).

There could be also cases of devices and controllers that although feature a battery protection, may still show up as devices with a cache to the kernel AND not ignore flush requests (so that barriers would have an effect on device caches irrespective of battery protection), and in those cases manually disabling barriers could have a performance benefit. Those cases should be rare, and the SysAdmin should ensure those assumptions with the hardware vendor (as they may compromise filesystem consistency if they don't hold true).

[1] https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-tuning-io.html#cha-tuning-io-barrier