Re: scsi vs ide performance on fsync's

[Jens Axboe <axboe@suse.de>]

On Tue, Mar 06 2001, David Balazic wrote:
> > > Wrong model 
> > > 
> > > You want a write barrier. Write buffering (at least for short intervals)
> > > in the drive is very sensible. The kernel needs to able to send
> > > drivers a write barrier which will not be completed with outstanding
> > > commands before the 
> > > barrier. 
> > 
> > Agreed. 
> > 
> > Write buffering is incredibly useful on a disk - for all the same reasons 
> > that an OS wants to do it. The disk can use write buffering to speed up 
> > writes a lot - not just lower the _perceived_ latency by the OS, but to 
> > actually improve performance too. 
> > 
> > But Alan is right - we needs a "sync" command or something. I don't know 
> > if IDE has one (it already might, for all I know). 
> 
> ATA , SCSI and ATAPI all have a FLUSH_CACHE command. (*)
> Whether the drives implement it is another question ...

(Usually called SYNCHRONIZE_CACHE btw)

SCSI has ordered tag, which fit the model Alan described quite nicely.
I've been meaning to implement this for some time, it would be handy
for journalled fs to use such a barrier. Since ATA doesn't do queueing
(at least not in current Linux), a synchronize cache is probably the
only way to go there.

> (*) references : 
>   ATA-6 draft standard from www.t13.org
>   MtFuji document from ????????

ftp.avc-pioneer.com

-- 
Jens Axboe