Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-35609

Atomic writes on Linux 6.13 kernel

Details

    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      MariaDB already supports atomic writes in rare cases.
      https://mariadb.com/kb/en/atomic-write-support/

      With the upcoming Linux kernel 6.13 update, atomic writes will be enabled for EXT4 and XFS file systems.
      https://www.phoronix.com/news/Linux-6.13-VFS-Untorn-Writes

      Could MariaDB leverage these changes?

      Attachments

        Issue Links

          is blocked by

          New Feature - A new feature of the product, which has yet to be developed. MDBF-854 Linux 6.13+ kernel to support Atomic Write development/testing

          • Major - Major loss of function.
          • Open
          links to

          Web Link LWN Article Howto by Kernel Developer Ritesh Harjani

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            danblack has been working on setting up an environment for testing this. I’m looking forward to that.

            On a related note, already Linux 6.11 introduced some sysfs files queue/atomic_write_unit_max_bytes, but those would only be 512 on my system. I did not yet check a HDD that would report queue/physical_block_size as 4096 bytes.

            As far as I understand, on a copy-on-write or a journaled-data file system, it should be technically possible to support arbitrary-size atomic writes even when the hardware was limited to smaller page sizes.

            marko Marko Mäkelä added a comment - danblack has been working on setting up an environment for testing this. I’m looking forward to that. On a related note, already Linux 6.11 introduced some sysfs files queue/atomic_write_unit_max_bytes , but those would only be 512 on my system. I did not yet check a HDD that would report queue/physical_block_size as 4096 bytes. As far as I understand, on a copy-on-write or a journaled-data file system, it should be technically possible to support arbitrary-size atomic writes even when the hardware was limited to smaller page sizes.
            danblack Daniel Black added a comment -

            For UI - statx syscall:

            https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c34fc6f26ab86d03a2d47446f42b6cd492dfdc56

            The information returned here is based on hardware and how the filesystem was created and the parameters there. Its unclear how copy-one-write/journal implementations map to atomic capabilities.

            note kernel still has atomic_write_segments_max hard coded to 1

            danblack Daniel Black added a comment - For UI - statx syscall: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c34fc6f26ab86d03a2d47446f42b6cd492dfdc56 The information returned here is based on hardware and how the filesystem was created and the parameters there. Its unclear how copy-one-write/journal implementations map to atomic capabilities. note kernel still has atomic_write_segments_max hard coded to 1

            People

              Unassigned Unassigned
              PavelCibulka Pavel Cibulka
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.