[MDEV-21867] Unsafe writes in fil_write_flushed_lsn() Created: 2020-03-04  Updated: 2022-02-03  Resolved: 2022-02-03

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.8.1

Type: Bug Priority: Major
Reporter: Eugene Kosov (Inactive) Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-11633 Make the InnoDB system tablespace opt... Open

 Description   

https://github.com/MariaDB/server/blob/395f23a10d44a63732dd69f79fb7372bc5834443/storage/innobase/fil/fil0fil.cc#L2042
This writes bypasses redo log and double buffer and thus allows whose database corruption.



 Comments   
Comment by Marko Mäkelä [ 2020-03-04 ]

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.

Comment by Marko Mäkelä [ 2020-03-04 ]

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.

Comment by Marko Mäkelä [ 2022-02-03 ]

This was fixed by MDEV-27199.

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