mardi 24 mars 2015

Understanding ext4/jbd2 transactions


I'm trying to debug a bit of trouble I'm having with I/O latency on a system using ext4, but I'm a bit stumped in that I don't understand its journalling as well as I'd like to.


What I'm wondering in particular is at what point disk blocks are actually written, both into the journal and "for real". My assumption thus far is that, when some metadata operation like, say, a rename(), is done by a user process, the filesystem will ensure that the disk blocks that the operation needs to touch are in the buffer cache, carry out the necessary changes in memory on the cached pages, while creating a jbd2 transaction that records the changed pages, and then, at some later point, write those pages into the journal, and then, only when that is done and at some further arbitrarily later point, write them into the filesystem proper. Please do correct me if I'm wrong somewhere in here.


Assuming I'm somewhat correct, I'm wondering what might trigger the write to the journal to be carried out. Is it when some more general FS/VM part of the kernel decides that it's time to flush the dirty pages? Is it when there is no more space in the journal to allocate for more transactions? What happens if the kernel needs to reclaim some of the dirty pages from the buffer cache? Would that trigger the journal-write and main-write in forced succession?


Also, what is the standard terminology? When I see a transaction being referred to being "committed", what does that mean, more precisely?



Aucun commentaire:

Enregistrer un commentaire