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

[Jens Axboe <jens.axboe@oracle.com>]

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