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

use fdatasync() for redo log where appropriate

Details

    Description

      Redo log files are fixed size files. They're almost never renamed. So, metadata is not changed. For such cases we can use `fdatasync()` which doesn't flush metadata, like `fsync()` does. That should bring use some performance.

      Attachments

        Issue Links

          is blocked by

          Task - A task that needs to be done. MDEV-18115 Remove dummy tablespace for the redo log

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Task - A task that needs to be done. MDEV-14425 Change the InnoDB redo log format to reduce write amplification

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Task - A task that needs to be done. MDEV-22177 more fsync() -> fdatasync() in InnoDB

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            kevg Eugene Kosov (Inactive) created issue -
            kevg Eugene Kosov (Inactive) made changes -
            Field Original Value New Value
            marko Marko Mäkelä made changes -
            marko Marko Mäkelä added a comment - - edited

            MDEV-14425 may introduce a format option for append-only log files. For that option, we may need to use fsync(). For the circular files, fdatasync() indeed seems sensible. Not having an up-to-date timestamps on the redo log files should not matter much.

            Edit: fdatasync() (as well as opening a file in O_DSYNC mode) does update the file size and allocation metadata. We would only need fsync() if we cared about file timestamps.

            marko Marko Mäkelä added a comment - - edited MDEV-14425 may introduce a format option for append-only log files. For that option, we may need to use fsync() . For the circular files, fdatasync() indeed seems sensible. Not having an up-to-date timestamps on the redo log files should not matter much. Edit: fdatasync() (as well as opening a file in O_DSYNC mode) does update the file size and allocation metadata. We would only need fsync() if we cared about file timestamps.
            kevg Eugene Kosov (Inactive) made changes -
            Description Redo log files are fixed size files. They're almost never renamed. So, metadata is not changed. For such cases we can use `fdatasync()` which doesn't flush metadata, like `fsyn()` does. That should bring use some performance. Redo log files are fixed size files. They're almost never renamed. So, metadata is not changed. For such cases we can use `fdatasync()` which doesn't flush metadata, like `fsync()` does. That should bring use some performance.
            kevg Eugene Kosov (Inactive) made changes -
            Fix Version/s 10.5.1 [ 24029 ]
            Fix Version/s 10.5 [ 23123 ]
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]
            julien.fritsch Julien Fritsch made changes -
            Fixing Priority 250
            kevg Eugene Kosov (Inactive) made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 102636 ] MariaDB v4 [ 134160 ]

            People

              kevg Eugene Kosov (Inactive)
              kevg Eugene Kosov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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