Subject: Re: More on FUA from userland
To: Bill Studenmund <wrstuden@netbsd.org>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 04/11/2006 07:51:40
--fUvfsPTz/SzOZDdw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2006 at 01:12:54PM -0700, Bill Studenmund wrote:
> Ok, so I would like input on one more aspect of letting userland request=
=20
> FUA. What do we do if the device/bus interface doesn't understand FUA?
>=20
> Now for SCSI, we will just set FUA in the CDB. If the device doesn't=20
> support it, it will (well, should) reject the command.
>=20
> The question is what do we do with busses (like ATA) that, AFAIK, don't
> natively understand FUA. In addition to ATA, another candidate would be
> RAID cards where you can't request FUA functionality.
>=20
> I see three options:
>=20
> 1) We don't worry about it. This point isn't so good as userland wanted=
=20
> FUA, and didn't get it. Yet it was told the operation conpleted. So we're=
=20
> lying. :-)
>=20
> 2) Make every device driver know about FUA and report an error if it's se=
t=20
> and not supported. Drawback is it's a lot of rototilage.
>=20
> 3) Make some layer further up the chain do the checking. The idea is that=
=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 idea=
=20
> would mean adding more infrastructure.

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.

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.

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.

--
Dan.

--fUvfsPTz/SzOZDdw
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEOtNsEAVxvV4N66cRArB9AKCUkm3SNRy4TzCti4eZHLuj3ix9WwCgqSwV
SlBc3JlB8b/hGjwjy2Gh0aU=
=N/y6
-----END PGP SIGNATURE-----

--fUvfsPTz/SzOZDdw--