> Jens Axboe wrote:
> > > Question is: does IDE need it at all? If we can assume
> > > that the data is safe once the drive has acked it, then that's
> > > all a journalling fs cares about, yes?
> > It would enable safe use of write caching, so yes. For a barrier write,
> > do a sync flush following a write/write_dma/write_dma_queued command
> > (yes dma_queued has no ordered/sync option, yay ide).
> There was some discussion a while back, (triggered by someone's
> benchmark where IDE was thrashing SCSI) where it turned out that
> some IDE disks were simply ignoring the flush command.
I think the issue was that write caching was on on ide disks by default
where on scsi it is usually off by default. The discussion was about O_SYNC,
and they got the expected performance by disabling the caching.
I think the only real answer is to write some tests which can be run
on a raw disk. Work out the cache size of a device and push about that
much data out to a raw disk, then drop the power. The tricky part is
dropping the power quickly enough, is it possible to hook into apm
or something and drop the power automatically? Then check that the
data made it to disk after power up. You would need to run lots of
cases to trust a device with write caching on.
This would at least give us a testbed for drives and is somewhat similar
to part of the process SGI uses to qualify scsi drives for hardware.
> Which is a quite sane thing to do if the write cache integrity
> is guaranteed in this manner.
> What's the story with other storage interfaces apart from SCSI?
> Seems that most of them implement SCSI in some way anyway - are
> there other technologies that need thinking about?