xfs
[Top] [All Lists]

Re: More on write caching

To: Jens Axboe <axboe@xxxxxxx>
Subject: Re: More on write caching
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 07 Jul 2001 21:32:29 +1000
Cc: Steve Lord <lord@xxxxxxx>, Andrew Klaassen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <ak@xxxxxxx> <20010706130636.C2814@xxxxxxx> <200107061738.f66Hcpb09219@xxxxxxxxxxxxxxxxxxxx> <3B469DDF.905AEC0B@xxxxxxxxxx>, <3B469DDF.905AEC0B@xxxxxxxxxx> <20010707131328.F16505@xxxxxxx> <3B46F0E5.77EAF1F9@xxxxxxxxxx>, <3B46F0E5.77EAF1F9@xxxxxxxxxx> <20010707132238.G16505@xxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
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.

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?

<Prev in Thread] Current Thread [Next in Thread>