Barriers and SYNCHRONZIE_CACHE

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.

Cheers,

Hannes

Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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