Re: RAIDframe: passing component capabilities (was: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL)

[Greg Oster <oster%netbsd.org@localhost>]

On Wed, 29 Mar 2017 12:02:23 +0200
Edgar Fuß <ef%math.uni-bonn.de@localhost> wrote:

> EF> Some comments as I probably count as one of the larger WAPBL
> EF> consumers (we have ~150 employee's Home and Mail on NFS on
> EF> FFS2+WAPBL on RAIDframe on SAS):
> JD> I've not changed the code in RF to pass the cache flags, so the
> JD> patch doesn't actually enable FUA there. Mainly because disks
> JD> come and go and I'm not aware of mechanism to make WAPBL aware of
> JD> such changes. It
> TLS> I ran into this issue with tls-maxphys and got so frustrated I
> TLS> was actually considering simply panicing if a less-capable disk
> TLS> were used to replace a more-capable one.  
> Oops. What did you do in the end? What does Mr. RAIDframe say?
> 
> My (probably simplistic) idea would be to add a capabilities option
> to the configuration file, and just as you can't add a disc with
> insufficient capacity, you can't add one with insufficient
> capabilities. Of course, greater capabilities are to be ignored just
> as a larger capacity is.

FUA/maxphys/anything 'disk'-specific is a bit of a pain to deal with,
given that RAIDframe (nor ccd, nor much else) has a general 'query the
underlying layers to ask about this capability' function.

I see two major things here:
 1) Whatever we do can't break existing setups.  That is, if an
 underlying disk can't do FUA, then upper layers just need to Deal.
 (NetBSD 8 refusing to configure a RAID set because of this is not an
 option.)

 2) Whatever query mechanism is used must be device agnostic at the
 higher levels.  It needs to work for RAID, SAS, SCSI, SATA, HP-IB,
 etc, and leave it up to the lower levels to respond with the correct
 "Yes all devices I talk to (recursively) can do this" or "No,
 at least one of us can't do this" to the query.  And then it's up to
 the drivers to actually pass the appropriate flags and do the Right
 Things.

Later...

Greg Oster