By design, the write is bypassing the redo log. It would be better to not bypass the doublewrite buffer.
I think that we should remove the function fil_write_flushed_lsn() and related checks in MariaDB 10.5.
I believe that the only purpose of FIL_PAGE_FILE_FLUSH_LSN is to write a message to the server error log when the redo log appears logically empty and its LSN does not correspond to the value of this field. The field is wasting 8 bytes in every data page, even though we only use it in the first page of the system tablespace. In MariaDB 10.1, the field was partly repurposed for encryption, and in MariaDB 10.2 (and MySQL 5.7), for the ‘split sequence number’ of SPATIAL INDEX.
Marko Mäkelä
added a comment - By design, the write is bypassing the redo log. It would be better to not bypass the doublewrite buffer.
I think that we should remove the function fil_write_flushed_lsn() and related checks in MariaDB 10.5.
I believe that the only purpose of FIL_PAGE_FILE_FLUSH_LSN is to write a message to the server error log when the redo log appears logically empty and its LSN does not correspond to the value of this field. The field is wasting 8 bytes in every data page, even though we only use it in the first page of the system tablespace. In MariaDB 10.1, the field was partly repurposed for encryption, and in MariaDB 10.2 (and MySQL 5.7), for the ‘split sequence number’ of SPATIAL INDEX .
Thanks to this field, it is safe to delete the redo log files are deleted after a clean shutdown, because the new redo log will be initialized based on the contents of the FIL_PAGE_FILE_FLUSH_LSN in the first page of the system tablespace. If we stop updating this field, then we should stop also creating the redo log automatically when data files exist. To allow startup, we would need a special startup option or an external tool to create empty log files as of a specified LSN.
Because of this, it could be too late to remove the writes to the field even in 10.5, which is rather close to feature freeze. But we definitely should consider that in 10.6, because eventually we want to make the system tablespace optional in MDEV-11633.
Marko Mäkelä
added a comment - Thanks to this field, it is safe to delete the redo log files are deleted after a clean shutdown, because the new redo log will be initialized based on the contents of the FIL_PAGE_FILE_FLUSH_LSN in the first page of the system tablespace. If we stop updating this field, then we should stop also creating the redo log automatically when data files exist. To allow startup, we would need a special startup option or an external tool to create empty log files as of a specified LSN.
Because of this, it could be too late to remove the writes to the field even in 10.5, which is rather close to feature freeze. But we definitely should consider that in 10.6, because eventually we want to make the system tablespace optional in MDEV-11633 .
Bug
Major
MDEV-11633 Make the InnoDB system tablespace optional
By design, the write is bypassing the redo log. It would be better to not bypass the doublewrite buffer.
I think that we should remove the function fil_write_flushed_lsn() and related checks in MariaDB 10.5.
I believe that the only purpose of FIL_PAGE_FILE_FLUSH_LSN is to write a message to the server error log when the redo log appears logically empty and its LSN does not correspond to the value of this field. The field is wasting 8 bytes in every data page, even though we only use it in the first page of the system tablespace. In MariaDB 10.1, the field was partly repurposed for encryption, and in MariaDB 10.2 (and MySQL 5.7), for the ‘split sequence number’ of SPATIAL INDEX.