http://bugzilla.suse.com/show_bug.cgi?id=1169774
http://bugzilla.suse.com/show_bug.cgi?id=1169774#c28
--- Comment #28 from Jan Kara ---
So some more data: One fsmark loop dirties ~812000 unique metadata blocks (this
is regardless of which writeback strategy is used). Now 'lock' runs do some 110
*millions* of metadata block dirty events, 'nolock' run does ~125 millions of
metadata block dirty events. So we see redirtying really happens a *lot* - one
block is redirtied over 100 times on average. Due to transaction batching, we
actually journal only ~5.5 millions of metadata blocks for 'lock' runs and ~7.5
millions of metadata blocks for 'nolock' runs - transactions are smaller so
batching is less efficient here. These differences match very well the
difference in the amount of writes we can see in comment 27 and explain the
performance difference. So I have now good understanding why the regression
happens.
Now I have to figure out if we can somehow improve this so that 'nolock' mode
isn't hit that badly.
--
You are receiving this mail because:
You are on the CC list for the bug.