Re: [patch] Add support for barriers to blk{back,front} drivers.

[Gerd Hoffmann <kraxel@suse.de>]

Ian Pratt wrote:
>  
>> It's about correctness, not about performance.  I've talked 
>> with Jens Axboe about it a while ago.  Barriers are 
>> *required* for journaling filesystems to work reliable.  
> 
> I just don't believe that. If the underlying device doesn't support
> barriers Linux should just stop issuing requests until it has the
> completion notifcation back for *all* the outstanding IOs to the device,
> and then start issuing the new batch of IOs.  

That is what actually happens, that isn't enough in all cases though.

> I'd be incredibly surprised if this is not what Linux does today for
> devices that don't support barriers. [NB: you still have the issue of
> disks that support write caching and lie and send the completion before
> data has hit the disk, but there's nothing you can do about that from
> the OS]

The write caching case is exactly the problematic one.  If you turn off
the disks write caching you are fine I think.  With write caching
enabled journaling is safe only together with barriers.  The kernel can
either use request tagging so the drive itself makes sure the write
order is correct or explicitly ask the drive to flush the write cache,
depending on what the hardware supports.

> I'd certainly be interested to see some benchmarks with and without the
> barrier support in blkfront/back.

I'll go run some ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg