Hello, I've recently got a bug report where JBD2 assertion failed due to transaction commit running out of journal space. After closer inspection of the crash dump it seems that the problem is that there were too many journal descriptor blocks (more that max_transaction_size >> 5 + 32 we estimate in jbd2_log_space_left()) due to descriptor blocks with revoke records. In fact the estimate on the number of descriptor blocks looks pretty arbitrary and there can be much more descriptor blocks needed for revoke records. We need one revoke record for every metadata block freed. So in the worst case (1k blocksize, 64-bit journal feature enabled, checksumming enabled) we fit 125 revoke record in one descriptor block. In common cases its about 500 revoke records per descriptor block. Now when we free large directories or large file with data journalling enabled, we can have *lots* of blocks to revoke - with extent mapped files easily millions in a single transaction which can mean 10k descriptor blocks - clearly more than the estimate of 128 descriptor blocks per transaction ;) This patch series aims at fixing the problem by accounting descriptor blocks into transaction credits and reserving appropriate amount of credits for revoke descriptors on transaction handle start. Similar to normal transaction credits, the filesystem has to provide estimate for the number of blocks it is going to revoke using the transaction handle so that credits for revoke descriptors can be reserved. The series has survived fstests in couple configurations and also the stress test of deleting large files in -o nodelalloc,data=journal configuration which reliably triggers the assertion failure in JBD2 on unpatched kernel. Review and comments are welcome :). Honza
