[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10553.1180717627@turing-police.cc.vt.edu>
Date: Fri, 01 Jun 2007 13:07:07 -0400
From: Valdis.Kletnieks@...edu
To: Tejun Heo <htejun@...il.com>
Cc: david@...g.hm, Stefan Bader <Stefan.Bader@...ibm.com>,
Phillip Susi <psusi@....rr.com>,
device-mapper development <dm-devel@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, Jens Axboe <jens.axboe@...cle.com>,
David Chinner <dgc@....com>,
Andreas Dilger <adilger@...sterfs.com>, ric@....com
Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
On Fri, 01 Jun 2007 16:16:01 +0900, Tejun Heo said:
> Don't those thingies usually have NV cache or backed by battery such
> that ORDERED_DRAIN is enough?
Probably *most* do, but do you really want to bet the user's data on it?
> The problem is that the interface between the host and a storage device
> (ATA or SCSI) is not built to communicate that kind of information
> (grouped flush, relaxed ordering...). I think battery backed
> ORDERED_DRAIN combined with fine-grained host queue flush would be
> pretty good. It doesn't require some fancy new interface which isn't
> gonna be used widely anyway and can achieve most of performance gain if
> the storage plays it smart.
Yes, that would probably be "pretty good". But how do you get the storage
device to *reliably* tell the truth about what it actually implements? (Consider
the number of devices that downright lie about their implementation of cache
flushing....)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists