[MDEV-24105] restore innodb osx F_FULLFSYNC to full glory (innodb) Created: 2020-11-03  Updated: 2023-11-13

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.34
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Daniel Black Assignee: Dmitry Shulga
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OSX


Issue Links:
Relates
relates to MDEV-32777 DDL operations very slow under macOS Open

 Description   

Without this OSX reliability isn't durable.

OSX man pages still strongly recommend F_FULL_SYNC for proper flushing to OSX storage.

MariaDB has this syscall in the mysys section, but not in innodb.

The last traces of F_FULLFSYNC were removed in MySQL 5.7.2 b890823b287cee10592b8c6e1cdd4e12e08c51f3 which where merged.

The use of `HAVE_DARWIN_THREADS` was problematic, however alternate OSX defines are readily accessible and correct - like _APPLE_.

The initial introduction mysql commits is 746fd9fdacc52ccc297db7703ea9288b67138167



 Comments   
Comment by Marko Mäkelä [ 2021-04-26 ]

Apple documentation also mentions F_BARRIERFSYNC. That should be sufficient for persisting writes to data files before normal log file writes, and also for persisting normal log file writes (those that advance log_sys.flushed_to_disk_lsn before page writes.

It would seem to me that only when we care about making a transaction commit durable and wait for log_sys.flushed_to_disk_lsn to be advanced at least to the LSN of the transaction commit, we must use F_FULLFSYNC.

Side note: On Linux ext4 file system, it appears that fdatasync() will do nothing after an O_DIRECT asynchronous write has completed.

Generated at Thu Feb 08 09:27:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.