[MDEV-18097] Indicate which InnoDB data files are zero-initialized Created: 2018-12-28  Updated: 2019-03-14  Resolved: 2019-02-27

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.4.3

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: init, upgrade

Attachments: File 10.1.patch    
Issue Links:
Relates
relates to MDEV-4259 transactional DDL Open
relates to MDEV-11623 MariaDB 10.1 fails to start datadir c... Closed
relates to MDEV-12026 Support encrypted SPATIAL INDEX Closed
relates to MDEV-12112 corruption in encrypted table may be ... Closed

 Description   

Originally, InnoDB did not zero-initialize buffer pool blocks that were allocated to a file page. Because of this, unused bytes on data pages could contain any garbage, belonging to the previous contents of the buffer pool block, such as another data page, or a generic memory allocation (BUF_BLOCK_MEMORY, buf_block_alloc(), MEM_HEAP_BUFFER) that is used by the adaptive hash index, crash recovery, record locks.

The page initialization was finally added in MySQL 5.1.48 for all data files. The original author of InnoDB opposed the initialization for many years, because he feared that it might cost some performance.

To make it easier to repurpose unused data fields in the future, we should introduce a flag in FSP_SPACE_FLAGS to indicate that any unused fields in the data file are zero-initialized.

At least since MDEV-11623 in MariaDB 10.1.21, InnoDB is ignoring the useless tablespace flag that was introduced in MySQL 5.6 to indicate that the DATA DIRECTORY attribute was specified when the table was created or rebuilt. Let us repurpose this old flag to indicate that unused data fields have been zero-initialized. (MySQL 5.6 and later always zero-initialized all unused data fields, so it is safe to repurpose this bit. It can never be set on files that were created before MySQL 5.6.)

We must be careful to never set this flag on old data files without first having rewritten all pages. This could be implemented in a conversion tool later.



 Comments   
Comment by Marko Mäkelä [ 2018-12-28 ]

10.1.patch attempts to implement this. There are a few failing tests.

There also is a downgrade problem. A prerequisite for implementing this should be to ensure that IMPORT TABLESPACE to older versions works.

Comment by Marko Mäkelä [ 2019-02-27 ]

After to MDEV-12026 in MariaDB 10.4, data files created with innodb_checksum_algorithm=full_crc32 will be guaranteed to be zero-initialized. The tablespace flag that indicates full_crc32 format is also indicating that the file contains no uninitialized garbage. (We do not support in-place update of old data files (which may contain uninitialized garbage) to the full_crc32 format.)

Comment by Geoff Montee (Inactive) [ 2019-03-01 ]

I updated the docs here:

https://mariadb.com/kb/en/library/innodb-encryption-troubleshooting/#tablespaces-created-on-mysql-5147-or-earlier

Are pages for tables with ROW_FORMAT=COMPRESSED guaranteed to be zero-initialized if MDEV-18644 is still open?

Generated at Thu Feb 08 08:41:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.