Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

[David Chinner <dgc@sgi.com>]

On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote:
> On Monday May 28, dgc@sgi.com wrote:
> > On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> > > Thanks everyone for your input.  There was some very valuable
> > > observations in the various emails.
> > > I will try to pull most of it together and bring out what seem to be
> > > the important points.
> > > 
> > > 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
> > 
> > Sounds good to me, but how do we test to see if the underlying
> > device supports barriers? Do we just assume that they do and
> > only change behaviour if -o nobarrier is specified in the mount
> > options?
> 
> What exactly do you want to know, and why do you care?

If someone explicitly mounts "-o barrier" and the underlying device
cannot do it, then we want to issue a warning or reject the
mount.

> The idea is that every "struct block_device" supports barriers.  If the
> underlying hardware doesn't support them directly, then they get
> simulated by draining the queue and issuing a flush.

Ok. But you also seem to be implying that there will be devices that
cannot support barriers.

Even if all devices do eventually support barriers, it may take some
time before we reach that goal.  Why not start by making it easy to
determine what the capabilities of each device are. This can then be
removed once we reach the holy grail....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/