[LFS/VM TOPIC] Barriers and SYNCHRONZIE_CACHE

[LFS/VM TOPIC] Barriers and SYNCHRONZIE_CACHE

[Hannes Reinecke]

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
hare@suse.de			      +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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Lsf10-pc] [LFS/VM TOPIC] Barriers and SYNCHRONZIE_CACHE

[Jens Axboe]

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