lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 27 Jan 2020 11:26:40 -0300 From: Red Swaqz <redswaqz@...il.com> To: linux-ext4@...r.kernel.org Subject: [QUESTION] jbd2: how metadata blocks are checkpointed by the page-cache? Hello all, I am studying the ext4/JBD2 internals and there is one thing that is missing in my understanding: the **Checkpoint** part for metadata blocks. So far I understood that the JBD2 marks the metadata buffers as _bufer_jbddirty(bh)_, then during the commit, the buffers are shadowed, written to the journal area, and later they are marked as _buffer_dirty(bh)_ and left to the page-cache to writeback them to the original position at the disk. Later on, the JBD2 will check its checkpoint list and check if the _buffer_heads_ are clean, which indicates that they were written to the storage and the CP operation is complete, thus JBD2 can remove those _buffer_heads_ from its control. So, this is the part I didn't catch in the code: where/when/how the page-cache writes the metadata blocks exactly? So far I could understand (not 100% sure) that the ext4 fills the _address_space_operations_ structure with the _ext4_writepage()_, _ext4_writepages()_, and so on for the page-cache operations. But still, it is not clear to me when the metadata blocks are written back to cause the CP completion. The writeback part for data blocks is OK because it looks to me that the page-cache uses the _inodes_ to be able to write them to the storage (with the data blocks). So, this is kinda easy to figure out in the source code. Anyone could help me with some insights into the source code or maybe theory? Thank you all.
Powered by blists - more mailing lists