Skip to content

linux-forced-unit-access.md

Latest commit

 

History

History
60 lines (37 loc) · 4.07 KB

linux-forced-unit-access.md

File metadata and controls

60 lines (37 loc) · 4.07 KB
author rwestMSFT
ms.author randolphwest
ms.date 07/03/2025
ms.service sql
ms.subservice linux
ms.topic include
ms.custom
linux-related-content

Certain versions of supported Linux distributions provide support for FUA I/O subsystem capability, which provides data durability. [!INCLUDE ssnoversion-md] uses the FUA capability to provide highly efficient and reliable I/O for [!INCLUDE ssnoversion-md] workloads. For more information on FUA support by Linux distribution and its effect on [!INCLUDE ssnoversion-md], see SQL Server On Linux: Forced Unit Access (FUA) Internals.

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0, and Ubuntu 18.04 introduced support for FUA capability in the I/O subsystem. If you're using [!INCLUDE sssql17-md] CU 6 and later versions, you should use following configuration for high performing and efficient I/O implementation with FUA by [!INCLUDE ssnoversion-md].

Use this recommended configuration if the following conditions are met.

  • [!INCLUDE sssql17-md] CU 6 and later versions

  • Linux distribution and version that supports FUA capability (starting with Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5, or Ubuntu 18.04)

  • XFS file system for [!INCLUDE ssnoversion-md] storage, on Linux kernel 4.18 or later versions.

  • ext4 file system for [!INCLUDE ssnoversion-md] storage, on Linux kernel 5.6 or later versions.

    [!NOTE]
    You should use the XFS filesystem for hosting [!INCLUDE ssnoversion-md] data and transaction log files when the Linux kernel version is lower than 5.6. Starting with the kernel version 5.6, you can choose between XFS and ext4 based on your specific requirements.

  • Storage subsystem and/or hardware that supports and is configured for FUA capability

Recommended configuration:

  1. Enable trace flag 3979 as a startup parameter.

  2. Use mssql-conf to configure control.writethrough = 1 and control.alternatewritethrough = 0.

For almost all other configuration that doesn't meet the previous conditions, the recommended configuration is as follows:

  1. Enable trace flag 3982 as a startup parameter (which is the default for [!INCLUDE ssnoversion-md] in the Linux ecosystem), and make sure that trace flag 3979 isn't enabled as a startup parameter.

  2. Use mssql-conf to configure control.writethrough = 1 and control.alternatewritethrough = 1.

FUA support for SQL Server containers deployed in Kubernetes

  1. The [!INCLUDE ssnoversion-md] must use persisted mounted storage, and not overlayfs.

  2. The storage must use the XFS or ext4 filesystems and should support FUA (ext4 does not support FUA on the Linux kernel earlier than version 5.6). Before enabling this setting, you should work with your Linux distribution and storage vendor, to ensure that the OS and storage subsystem supports FUA options. On Kubernetes, you can query for the filesystem type using the following command, where <pvc-name> is your PersistentVolumeClaim:

    kubectl describe pv <pvc-name>

    In the output, look for the fstype that is set to XFS.

  3. The worker node hosting the [!INCLUDE ssnoversion-md] pods, should be using a Linux distribution and version that supports FUA capability (starting with Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5, or Ubuntu 18.04).

If the above conditions are met, then you can use the following recommended FUA settings.

  1. Enable trace flag 3979 as a startup parameter.

  2. Use mssql-conf to configure control.writethrough = 1 and control.alternatewritethrough = 0.