--H1spWtNR+x+ondvy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 11, 2006 at 07:51:40AM +1000, Daniel Carosone wrote:
> On Mon, Apr 10, 2006 at 01:12:54PM -0700, Bill Studenmund wrote:
> > 3) Make some layer further up the chain do the checking. The idea is th=
at=20
> > devices that support FUA would somehow announce this, and code further =
up=20
> > the i/o stack will test and flag an error if needed. Issue here is how =
do=20
> > we announce this. I don't think we annoucne such things now, so this id=
ea=20
> > would mean adding more infrastructure.
>=20
> As well as the additional infrastructure, 3 sounds like it would need
> ~as much rototillage as 2, since each driver would still have to know
> and announce its capability - regardless of whether via an error path
> or a config-time path.

Not really. If we hook the code into the "right" layer, we can set stuff=20
up on open. And devices that can't do this can just error out however we=20
get the info (probably an ioctl).

> Option 1 doesn't sound so great, but the question for some devices is
> whether we can ever tell.  I would rather err on the side of caution
> for sucky devices, and turn an FUA into a cache sync (for writes)
> where we have no other option, than lie. If the device is lying to the
> kernel (in either case), that's beyond our control. If a full sync
> results in unacceptable performance, the user needs to adjust either
> their hardware or their expectations; maybe there should be an option
> around this behaviour, but that may also belong in configuring the
> application to just give up on consistency contstraints it can't
> achieve.

My thought at the moment is that if we take steps to not lie and the=20
device can't do FUA, then we just error out. If someone wants to come in=20
later and add "FUA via cache flush", that's fine. I'd rather keep this=20
project workable, though. :-)

> In summary: we shouldn't lie.  if we can detect an error, we should
> report it, but I wonder whether we can in all cases.  we may wish to
> emulate FUA via other mechanisms like cache sync, rather than fail
> outright, especially when we're in doubt about the previous.

As above, I'd like to leave compat code to a second pass/someone else.=20
However I now suspect that we can do something along the lines of option 3=
=20
in the original EMail.

Take care,

Bill

--H1spWtNR+x+ondvy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEOv7XWz+3JHUci9cRApMoAJ9sLi+ZBYnX/5Iz5xHu+QFs2hwChQCglkIz
ir02SEypREDOYE95aqQ5K1M=
=q8u6
-----END PGP SIGNATURE-----

--H1spWtNR+x+ondvy--