Hi Kristian, Finally, I got some more time to think about this. I’m trying to summarize from the InnoDB point of view what we discussed today. * We do not need any InnoDB buf_block_t or fil_space_t for any binlog files. * The binlog layer can simply append pages to binlog files (or rewrite the last page), whenever it pleases, in its preferred format. * The redo log records will cover writes to the binlog blocks before any encryption. ** As the first cut, only WRITE and possibly MEMSET records, covering the entire block (excluding checksum) * For durability, it is the InnoDB log write that matters. * Based on the binlog file creation LSN (in the first block, say, 4096 bytes), InnoDB recovery will: ** ignore files that are older than the checkpoint LSN ** delete files that are newer than the last recovered LSN ** recover any other files (re-apply writes or trim the contents after the last write) ** not read anything from the files ** invoke a pwrite() like binlog API that takes care of any encryption ** make sure that there are only WRITE, MEMSET, MEMMOVE records, in strictly sequential order * InnoDB log checkpoint will be tweaked as follows: ** The log checkpoint must not "split" a binlog write. ** InnoDB must remember the start LSN of the last partial binlog block write. ** Checkpoint_LSN=min(last_start_LSN,buf_pool.get_oldest_modification()): ** Before or after fil_flush_file_spaces(), the last binlog file must be durably written. last block padded. I will start to implement the log writing and recovery logic. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc