On Fri, Oct 04, 2019 at 12:06:04AM +0200, Jan Kara wrote: > Extend functions for starting, extending, and restarting transaction > handles to take number of revoke records handle must be able to > accommodate. These functions then make sure transaction has enough > credits to be able to store resulting revoke descriptor blocks. Also > revoke code tracks number of revoke records created by a handle to catch > situation where some place didn't reserve enough space for revoke > records. Similarly to standard transaction credits, space for unused > reserved revoke records is released when the handle is stopped. > > On the ext4 side we currently take a simplistic approach of reserving > space for 1024 revoke records for any transaction. This grows amount of > credits reserved for each handle only by a few and is enough for any > normal workload so that we don't hit warnings in jbd2. We will refine > the logic in following commits. > > Signed-off-by: Jan Kara <jack@xxxxxxx> So let me summarize the way I think this commit is handling things. 1) When a handle is created, the caller specifies how many revokes it plans to do. If during the life of the handle, more than this number of revokes are done, a warning will be emited. 2) For the purposes of reserving transaction credits, when we start the handle we assume the worst case number of number of revoke descriptors necessary, and we reserve that much space, and we add it to t_oustanding_credits. 3) When we stop the handle, we decrement t_outstanding_credits by the number of blocks that were originally reserved for this handle --- but *not* the number of worst case revoke descriptor blocks needed. Which means that after the handle is started and then closed, t_outstanding_credits will be increased by ROUND_UP((max # of revoked blocks) / # of revoke blocks per block group descriptor). If we delete a large number of files which are but a single 4k block in data=journal mode, each deleted file will increase t_outstanding_credits by one block, even though we won't be using anywhere *near* that number of blocks for revoke blocks. So we will end up closing the transactions *much* earlier than we would have. It also means that t_outstanding_credits will be a much higher number that we would ever need, so it's not clear to me why it's worth it to decrement t_outstanding_credits in jbd2_journal_get_descriptor_buffer() and warn if it is less than zero. And it goes back to the question I had asked earler: "so what is the formal definition of t_outstanding_credits after this patch series, anyway"? - Ted
