> On Mon, 2006-09-11 at 11:46 +0200, Jan Kara wrote: > ... > > > > > > I don't have any performance tests handy. We have some automated tests I > > > can schedule to run to verify the stability aspects. > > OK. I've run IOZONE rewrite throughput test on my computer with > > iozone -t 10 -i 0 -s 10M -e > > 2.6.18-rc6 and the same kernel + my patch seem to give almost the same > > results. The strange thing was that both in vanilla and patched kernel there > > were several runs where a write througput (when iozone was creating the file) > > was suddenly 10% of the usual value (18MB/s vs. 2MB/s). The rewrite numbers > > were always fine. Maybe that has something to do with block allocation > > code. Anyway, it is not a regression of my patch so unless your test > > finds some problem I think the patch should be ready for inclusion into > > -mm... > > Your patch seems to be working fine. I haven't found any major > regression yet. > > I spent lot of time trying to reproduce the problem with buffer-debug > Andrew sent out - I really wanted to get to bottom of whats really > happening here (since your patch made it go away). > > Yes. Your theory is correct. journal_dirty_data() is moving the > buffer-head from commited transaction to current one and > journal_unmap_buffer() is discarding and cleaning up the buffer-head. > Later set_page_dirty() dirties the buffer-head there by causing > BUG() in submit_bh(). > > Here is the buffer-trace-debug output to confirm it. I can sleep better > now :) Now we can figure out, if your fix is the right one or not .. OK, good to hear :). My patch should be prone at least to this problem (I'm not saying it could not have introduced any other ;). It locks the buffer and if it needed to drop JBD spin locks, it also checks whether the buffer remained in the BJ_SyncData list. Hence if the journal_dirty_data() steals the buffer while we are locking it we find that out and forget about the buffer. Once the buffer is locked, journal_dirty_data() won't touch it. I guess the patch is good enough to send it to Andrew... Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
