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

MariaDB 5.5 does not use fdatasync()

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Fixed
    • 5.5.24
    • 5.5.25
    • None
    • None

    Description

      I discovered a serious problem in 5.5 related to fsync (5.3 and below appears
      not affected).

      By default, we do not run any fsync at all. This is because the
      --debug-no-sync option is incorrectly enabled by default.

      This problem was introduced here:

      revid:sergii@pisem.net-20111212225840-8aotf02a1alw1gta

      • {"sync_sys", 0, - "Enable system sync calls. Disable only when running tests or debugging!", - &opt_sync, &opt_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0}

        ,
        +

        {"debug-no-sync", 0, + "Disables system sync calls. Only for running tests or debugging!", + &my_disable_sync, &my_disable_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0}

        ,

      The option was renamed and the meaning was reversed - but the default was left
      unchanged, effectively reversing the default.

      We need to fix this ASAP, as it causes data loss / silent corruption when the
      host machine crashes.

      There is an additional problem that even with --debug-no-sync=0, we are using
      fsync(), not fdatasync() as we should. There is code to use fdatasync(), but
      apparently availability of fdatasync() is not correctly detected by
      cmake. This is also a quite serious issue; one one machine I tested with a
      good RAID controller, fdatasync() is 2.5 times faster than fsync().

      Work-around: pass --debug-no-sync=0 in config or on command line (but this will not fix fdatasync() performance problem).

      Attachments

        Activity

          knielsen Kristian Nielsen created issue -
          knielsen Kristian Nielsen made changes -
          Field Original Value New Value
          Description I discovered a serious problem in 5.5 related to fsync (5.3 and below appears
          not affected).

          By default, we do not run any fsync at all. This is because the
          --debug-no-sync option is incorrectly enabled by default.

          This problem was introduced here:

          revid:sergii@pisem.net-20111212225840-8aotf02a1alw1gta

          - {"sync_sys", 0,
          - "Enable system sync calls. Disable only when running tests or debugging!",
          - &opt_sync, &opt_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0},
          + {"debug-no-sync", 0,
          + "Disables system sync calls. Only for running tests or debugging!",
          + &my_disable_sync, &my_disable_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0},

          The option was renamed and the meaning was reversed - but the default was left
          unchanged, effectively reversing the default.

          We need to fix this ASAP, as it causes data loss / silent corruption when the
          host machine crashes.

          There is an additional problem that even with --debug-no-sync=0, we are using
          fsync(), not fdatasync() as we should. There is code to use fdatasync(), but
          apparently availability of fdatasync() is not correctly detected by
          cmake. This is also a quite serious issue; one one machine I tested with a
          good RAID controller, fdatasync() is 2.5 times faster than fsync().
          I discovered a serious problem in 5.5 related to fsync (5.3 and below appears
          not affected).

          By default, we do not run any fsync at all. This is because the
          --debug-no-sync option is incorrectly enabled by default.

          This problem was introduced here:

          revid:sergii@pisem.net-20111212225840-8aotf02a1alw1gta

          - {"sync_sys", 0,
          - "Enable system sync calls. Disable only when running tests or debugging!",
          - &opt_sync, &opt_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0},
          + {"debug-no-sync", 0,
          + "Disables system sync calls. Only for running tests or debugging!",
          + &my_disable_sync, &my_disable_sync, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0},

          The option was renamed and the meaning was reversed - but the default was left
          unchanged, effectively reversing the default.

          We need to fix this ASAP, as it causes data loss / silent corruption when the
          host machine crashes.

          There is an additional problem that even with --debug-no-sync=0, we are using
          fsync(), not fdatasync() as we should. There is code to use fdatasync(), but
          apparently availability of fdatasync() is not correctly detected by
          cmake. This is also a quite serious issue; one one machine I tested with a
          good RAID controller, fdatasync() is 2.5 times faster than fsync().

          Work-around: pass --debug-no-sync=0 in config or on command line (but this will not fix fdatasync() performance problem).
          knielsen Kristian Nielsen made changes -
          Summary fdatasync() disabled by default MariaDB 5.5 does not use fdatasync()
          serg Sergei Golubchik made changes -
          Assignee Kristian Nielsen [ knielsen ]
          knielsen Kristian Nielsen made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow defaullt [ 12153 ] MariaDB v2 [ 45207 ]
          ratzpo Rasmus Johansson (Inactive) made changes -
          Workflow MariaDB v2 [ 45207 ] MariaDB v3 [ 65870 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 65870 ] MariaDB v4 [ 144836 ]

          People

            knielsen Kristian Nielsen
            knielsen Kristian Nielsen
            Votes:
            0 Vote for this issue
            Watchers:
            1 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.