Re: XFS and write barrier

[David Chinner <dgc@sgi.com>]

On Tue, Jul 18, 2006 at 08:27:48PM +0200, Martin Steigerwald wrote:
> Am Dienstag 18 Juli 2006 19:04 schrieb David Chinner:
> 
> > > "Journalling filesystems need write barrier" isn't really accurate.
> > > They can make good use of write barrier if it is supported, and where
> > > it isn't supported, they should use blkdev_issue_flush in combination
> > > with regular submit/wait.
> >
> > blkdev_issue_flush() causes a write cache flush - just like a
> > barrier typically causes a write cache flush up to the I/O with the
> > barrier in it.  Both of these mechanisms provide the same thing - an
> > I/O barrier that enforces ordering of I/Os to disk.
> 
> Hello David,
> 
> well now it gets interesting. If both provide the same thing, whats the 
> difference?

A WRITE_BARRIER I/O can be optimised by smart drivers, protocols and hardware
to minimise the adverse effects of the barrier, whereas a cache flush
is a brute force cache cleaning mechanism that cannot be optimised....

> > Given that filesystems already indicate to the block layer when they
> > want a barrier, wouldn't it be better to get the block layer to issue
> > this cache flush if the underlying device doesn't support barriers
> > and it receives a barrier request?
> 
> Does a device need to support more than this cache flush in order to 
> support barriers? Up to know I thought that when a device supports cache 
> flushes the kernel can provide barrier functinality for it.

Not necessarily as different device/protocol commands are used.

> I see in boot output that my notebook harddisk supports cache flushes. But 
> not in dmesg nor in syslog. I don't know yet how to actually determine 
> whether barrier functionality is really usable on a certain system. 

My test is to mount an XFS filesystem using barriers on the device and
look at the syslog message. ;)

> > FWIW, Only XFS and Reiser3 use this function, and only then when
> > issuing a fsync when barriers are disabled to make sure a common
> > test (fsync then power cycle) doesn't result in data loss...
> 
> So will XFS be safe even without write barriers?

XFS is only safe when you have:

	a) no write caching on the drive (barrier or nobarrier)
	b) non-volatile write caching on the drive (barrier or nobarrier)
	c) volatile write caching and barriers supported and enabled

The same conditions hold true for any filesystem that requires I/O ordering
guarantees to maintain filesystem consistency...

> What will it do when it 
> cannot do write barriers but write barriers are requested by the user or 
> the inbuilt default setting of the filesystem?  Will it work unsafely or 
> will mount readonly or disable write caches in that case?

XFS will log a warning to the syslog and dmesg saying write barriers are
disabled and continue onwards without barriers.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group