The writing of modified InnoDB data pages to data files should be overhauled. See some of the comments in MDEV-15058.
Execute InnoDB crash recovery in the background
Defer writes to the InnoDB temporary tablespace
Replace buf_pool.flush_list with a priority queue
Implement event-driven innodb_adaptive_flushing=OFF that ignores innodb_io_capacity
Reduce buf_pool_t::mutex contention
Remove dummy tablespace for the redo log
Defer change buffer merge until pages are requested
10.5 performance regression with IO-bound tpcc
AliSQL: [Perf] Issue#23 MERGE INNODB AIO REQUEST
AliSQL: [Feature] Issue#19 BUFFER POOL LIST SCAN OPTIMIZATION
Remove multiple InnoDB buffer pool instances
Upgrading to 10.1.32 shows innodb_empty_free_list_algorithm=BACKOFF as default when it should be 'LEGACY'
mariadb service won't shutdown when it's running and the OS datetime updated backwards
Assertion 'space->free_limit == 0 || space->free_limit == free_limit'
Page compression - use smaller writes, avoid trimming/zeroing rest of the page if possible
Avoid writes of freed (garbage) pages to InnoDB data files
[Note] InnoDB: page_cleaner: 1000ms intended loop took XXXXms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
Change the InnoDB redo log format to reduce write amplification
Error log flood : "InnoDB: page_cleaner: 1000ms intended loop took N ms. The settings might not be optimal."
Avoid writing freed InnoDB pages
Engine transaction recovery through persistent binlog
FOSDEM 2019: PostgreSQL vs. fsync
Historical - InnoDB IO Performance
MySQL Bug #94912 O_DIRECT_NO_FSYNC possible write hole
PostgreSQL's fsync() surprise
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS