On Mon, Feb 13 2012 at 1:13pm -0500, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Mon, Feb 13 2012 at 12:53pm -0500, > Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > > > Mike> So that makes 3 different _prominent_ storage vendors, that I am > > Mike> aware of, that are bitten by their broken storage (relative to > > Mike> discard and properly advertising which variant they actually > > Mike> support). I'd much rather deal with the storage vendors (or their > > Mike> customers) reporting that discards aren't working than mutual > > Mike> customers reporting that they cannot even install to the storage. > > > > More graceful handling of the sense data aside, we do have a couple of > > options: > > > > 1. Now that the provisioning portion seems to be stable in SBC-3 we can > > nuke the interim spec heuristics and only support devices that > > report the right thing. This may disable provisioning for some > > existing users whose arrays run non-compliant firmware. > > > > 2. We can add another layer of heuristics based on the RSOC wrapper I > > introduced for write same. Maybe you could send me sg_opcodes output > > for the arrays in question? > > Yeah, I think that would be welcomed evolution (but as you say, > independent of improving additional ILLEGAL REQUEST processing). That was a response to 1 above. I don't have direct access to the arrays in question to get sg_opcodes. But I can work on getting them. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
