On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote: > On Monday May 28, [EMAIL PROTECTED] 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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
