Ewan,

> sd_fops->revalidate_disk() will cause the properties that cause the
> provisioning_mode to be evaluated to be re-read, and sd_config_discard()
> to set the determined mode.  We might want to re-think this, since the
> user overrode what was probed earlier.  However, we might also want to
> automatically handle the storage capabilities changing, so I'm not
> sure.

The intent was for people to use udev to override things. But I guess we
could entertain introducing a flag to distinguish between detected and
configured state.

> My reading of SBC-4r13 6.6.4 is that a WRITE SAME(16) w/UNMAP has
> a length limited by the MAXIMUM WRITE SAME LENGTH, and that is what
> sd.c implements, but I'm suspicious that the array treated a WRITE SAME(16)
> w/UNMAP of 2097152 blocks as an UNMAP and failed it w/ILLEGAL COMMAND,
> INVALID FIELD IN CDB.

Ugh :(

-- 
Martin K. Petersen      Oracle Linux Engineering

Reply via email to