[Top] [All Lists]

Re: More on write caching

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: More on write caching
From: Jens Axboe <axboe@xxxxxxx>
Date: Sat, 7 Jul 2001 13:22:38 +0200
Cc: Steve Lord <lord@xxxxxxx>, Andrew Klaassen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <3B46F0E5.77EAF1F9@xxxxxxxxxx>
References: <ak@xxxxxxx> <20010706130636.C2814@xxxxxxx> <200107061738.f66Hcpb09219@xxxxxxxxxxxxxxxxxxxx> <3B469DDF.905AEC0B@xxxxxxxxxx>, <3B469DDF.905AEC0B@xxxxxxxxxx> <20010707131328.F16505@xxxxxxx> <3B46F0E5.77EAF1F9@xxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Sat, Jul 07 2001, Andrew Morton wrote:
> Jens Axboe wrote:
> > 
> > On Sat, Jul 07 2001, Andrew Morton wrote:
> > > For more sophisticated storage systems such as RAID controllers,
> > > I guess we'd have to propagate a SCSI write barrier command down to
> > > the controller itself.  I'm not sure that the Linux request
> > > and SCSI layers are up to doing that.  Have you looked into it?
> > 
> > I have, I wrote a barrier write patch some time ago. SCSI support is the
> > easy part, having the luxury of just setting a tag option.
> Good.  Please keep that patch warm.

I've tried to, and I'll put it in the bio-XX patches soon enough.

> 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).

Jens Axboe

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