Bug #107331 Problems around O_DIRECT
Submitted: 18 May 2022 13:19 Modified: 18 May 2022 15:43
Reporter: Mikael Ronström Email Updates:
Status: Verified Impact on me:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:8.0.29 OS:Any
Assigned to: CPU Architecture:Any

[18 May 2022 13:19] Mikael Ronström
A number of bugs were found around O_DIRECT when investigating
problems with O_DIRECT running on Asahi Linux on an Apple M1 Pro

1) Whether O_DIRECT works or not cannot be checked on an empty file
or on a new file. This is currently assumed that O_DIRECT is working.

2) Tablespace files rely on O_DIRECT to work. Mac OS X doesn't even support
O_DIRECT, so obviously not working there. Need to ensure that O_SYNC or
using fsync on each write is used instead when O_DIRECT isn't working
in this case.

3) Initilisation of O_DIRECT flag in LGMAN wasn't checking the config variable.
4) Initialisation of encrypted flag in LGMAN wasn't done.
5) ODirectSyncFlag was used also with Sparse REDO logs. This is not safe.
6) Implementation using O_DIRECT assumes that O_DIRECT works with 512 byte offsets and alignments. 

How to repeat:
Various ways

Suggested fix:
Ensure that O_DIRECT is enabled after init:ing the file.
Ensure that tablespace files gets sync:ed on each write always.
Ensure that REDO log doesn't use ODirectSyncFlag unless full init
is used on REDO logs.
Initialise O_DIRECT flag and encrypted flag in LGMAN.
[18 May 2022 15:43] MySQL Verification Team
Hello Mikael,

Thank you for the report and feedback.

[30 May 2022 11:45] Mauritz Sundell
Posted by developer:
Issue 4) is Bug#34185524 LGMAN use undefined encrypted filesystem setting