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