Are ZIL writes (lwbs) supposed to be atomic per txg? Does ZIL-replay discard partially written txgs?

[dgiantsidi]

Hi there,

I'd like some help to understand the following regarding ZIL writes in a transaction group synchronization or when we do zil_commit() (due to an fsync()).
The ZIL in zil_lwb_assign() might split the itxg_list and assign its parts to different lwbs when there is no room in the single current lwb.
And then for each of these lwbs, zil_lwb_write_issue() will fill them with data (zil_lwb_commit()) and issue a IO-request. I understand that the lwbs and the IOs are respecting an ordering imposed by the itxg_list.

However, it seems to me that the updates of single transaction group (itgx) are splitted into many lwbs right?
Does ZIL guarantee atomic writes per txg or per lwb (of course ZIL does not have integrity protection) ? In other words, it is possible that only some (but not all) lwbs are written to the disk due to a crash. How ZIL understands at recovery that a txg is written partially?

Thanks,
Demy

[amotin]

From the point of ZIL, that is sure possible that only some of lwbs issued by fsync()/zil_commit() are written before the crash. And on a following import only what was written will be replayed, that might split some write operation. But in that case the caller of fsync()/zil_commit() should not get the function return before the crash, so there is no valid contract yet. fsync() does not promise anything until it returns.

From the point of TXG commits (without fsync()) writes might actually be more atomic, since writes up to a certain size might be assigned to one TXG and so committed or not atomically, but those guaranties are just a ZFS internal implementation details and not exposed externally.

[dgiantsidi]

Thank you super much for the clarification and the prompt reply!