Messages in this thread | | | From | Neil Brown <> | Date | Thu, 31 May 2007 10:46:04 +1000 | Subject | Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md. |
| |
On Monday May 28, dgc@sgi.com wrote: > On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote: > > 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.
I guess that makes sense. But apparently you cannot tell what a device supports until you write to it. So maybe you need to write some metadata with as a barrier, then ask the device what it's barrier status is. The options might be: YES - barriers are fully handled NO - best effort, but due to missing device features, it might not work DISABLED - admin has requested that barriers be ignored.
??
> > > 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.
It seems there will always be hardware that doesn't meet specs. If a device doesn't support SYNCHRONIZE_CACHE or FUA, then implementing barriers all the way to the media would be hard..
> > 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....
I'd rather not add something that we plan to remove. We currently have -EOPNOTSUP. I don't think there is much point having more than that.
I would really like to get to the stage where -EOPNOTSUP is never returned. If a filesystem cares, it could 'ask' as suggested above. What would be a good interface for asking? What if the truth changes (as can happen with md or dm)?
NeilBrown - 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/
| |