On Tue, May 25 2010, Hannes Reinecke wrote: > Hi all, > > [Topic] > Barriers and SYNCHRONIZE CACHE > > [Abstract] > In recent years some design flaws in the barriers implementation > became apparent: > - No indication about _which_ blocks to flush, so all outstanding > blocks are flushed > - No error handling for SYNCHRONIZE CACHE > - SYNCHRONIZE CACHE affects all I/Os, so if a LUN is used by > several virtual guests _all_ guests are affected > - SYNCHRONIZE CACHE has a rather severe performance impact > on RAID controllers (if executed directly) > > To overcome these issues I would propose to modify the > barrier interface so that individual blocks can be > marked as 'flushing'/'immediate'. This would allow > the lower layers (eg. SCSI midlayer) to restrict > the barriers operation on the affected blocks only. > EG the SYNCHRONIZE_CACHE operation could be updated > with a block list. Or more advanced methods (like FUA > or tagging) could be used, avoiding the need to issue > a SYNCHRONIZE CACHE altogether. I think this is better handled over email for several reasons. Here's a few of them: - We've talked about barriers at each io/fs summit since we started holding those, and nothing has ever come out of it. Lets not waste more time _talking_ about it. - Following from the previous entry, this is now at a point (and has been for probably 5 years) where the best way forward is discussion based on actual code. - Yet another hand wavy discussion on how to improve barriers turns hair greyer. And at least personally, I don't need more grey hairs. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
