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
|