Hi,Tests are still running fine.
Jan Kara wrote:Great, thanks. BTW: Do you have any performance tests handy? The
I've been looking more at the code and I have revived my patch fixingI have been running 4+ hours with this patch and seems to work fine. I haven't hit any
this part of the code. I've mildly tested the patch. Could you also give
it a try? Thanks.
Honza
------------------------------------------------------------------------
Original commit code assumes, that when a buffer on BJ_SyncData list is locked,
it is being written to disk. But this is not true and hence it can lead to a
potential data loss on crash. Also the code didn't count with the fact that
journal_dirty_data() can steal buffers from committing transaction and hence
could write buffers that no longer belong to the committing transaction.
Finally it could possibly happen that we tried writing out one buffer several
times.
The patch below tries to solve these problems by a complete rewrite of the data
commit code. We go through buffers on t_sync_datalist, lock buffers needing
write out and store them in an array. Buffers are also immediately refiled to
BJ_Locked list or unfiled (if the write out is completed). When the array is
full or we have to block on buffer lock, we submit all accumulated buffers for
IO.
Signed-off-by: Jan Kara <jack@xxxxxxx>
assert yet :)
I will let it run till tomorrow. I will let you know, how it goes.
changes are big enough to cause some unexpected performance regressions,
livelocks... If you don't have anything ready, I can setup and run
something myself. Just that I don't like this testing too much ;).