# Safety of O\_DIRECT\_NO\_FSYNC for MySQL 8.0.Server version: 8.0.35-27? **URL:** \ **Category:** Percona Distribution for MySQL\ **Tags:** mysql\ **Created:** [February 24, 2025, 8:32pm UTC](https://forums.percona.com/t/safety-of-o-direct-no-fsync-for-mysql-8-0-server-version-8-0-35-27/36901 "2025-02-24T20:32:38Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![J\_S](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/j_s/32/12343_2.png) [@J\_S](https://forums.percona.com/u/J_S)\ **Post date:** [February 24, 2025, 8:32pm UTC](https://forums.percona.com/t/safety-of-o-direct-no-fsync-for-mysql-8-0-server-version-8-0-35-27/36901/1 "2025-02-24T20:32:38Z")
I have xfs on ebs attached volumes and have been testing and reading MySQL and Percona documentation for O\_DIRECT\_NO\_FSYNC which seems to lower what I am seeing as a HUGE increase in I/O activity since 5.7… Is it safe? According to Percona Docs : ``` `O_DIRECT_NO_FSYNC`: use O\_DIRECT to open the data files and parallel doublewrite files, but does not use the `fsync()` system call to flush the data files, log files, and parallel doublewrite files. Do not use this option for the _XFS_ file system. ```auto Acc to MySQL: `O_DIRECT_NO_FSYNC`: `InnoDB` uses `O_DIRECT` during flushing I/O, but skips the `fsync()` system call after each write operation. Prior to MySQL 8.0.14, this setting is not suitable for file systems such as XFS and EXT4, which require an `fsync()`system call to synchronize file system metadata changes. If you are not sure whether your file system requires an `fsync()`system call to synchronize file system metadata changes, use `O_DIRECT` instead. As of MySQL 8.0.14, `fsync()` is called after creating a new file, after increasing file size, and after closing a file, to ensure that file system metadata changes are synchronized. The `fsync()` system call is still skipped after each write operation. ``` ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [February 24, 2025, 10:02pm UTC](https://forums.percona.com/t/safety-of-o-direct-no-fsync-for-mysql-8-0-server-version-8-0-35-27/36901/2 "2025-02-24T22:02:57Z")
> [@J\_S](#): > > does not use the `fsync()` system call to flush the data files, log files, and parallel doublewrite files. Even if you are on 8.0.14+, this says fsync() won’t be called when InnoDB writes a block to data (.ibd) files, or to the doublewrite buffer (used to protect against partial page writes). Running without the fsync is indeed faster, but you open yourself to risk of data loss/file corruption. Try testing O\_DIRECT + innodb\_flush\_log\_at\_trx\_commit=2. This will skip the “fsync on every commit” but still fsync every 1s. Also, reduce fsync to the binlogs by using sync\_binlog=500 (fsync every 500 txns) ---
**Author:** ![J\_S](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/j_s/32/12343_2.png) [@J\_S](https://forums.percona.com/u/J_S)\ **Post date:** [February 25, 2025, 3:35pm UTC](https://forums.percona.com/t/safety-of-o-direct-no-fsync-for-mysql-8-0-server-version-8-0-35-27/36901/3 "2025-02-25T15:35:01Z")
Ah ok, yes. Then I will stick with O\_DIRECT. Why am I seeing almost 10x the innodb fsyncs() from 5.7 and 8.0? And what is best practice to lower that thrash? ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [February 25, 2025, 4:09pm UTC](https://forums.percona.com/t/safety-of-o-direct-no-fsync-for-mysql-8-0-server-version-8-0-35-27/36901/4 "2025-02-25T16:09:24Z")
> [@J\_S](#): > > Why am I seeing almost 10x the innodb fsyncs() from 5.7 and 8.0? This gets tossed into the generic “8.0 made lots of internal changes to improve various things” bucket 🙂