On Wed, 12 Jun 2013, Bernd Schubert wrote: > On 06/12/2013 06:07 AM, H. Peter Anvin wrote: > > On 06/11/2013 08:15 PM, NeilBrown wrote: > >> If a drive reports that WRITE SAME works, but it doesn't, then I'm > >> not sure that I can be happy about working with that drive. > > > > Seriously... we have that kind of problems all over the place with all > > kinds of hardware. Falling back is sensible... the problem here is > > *where* that needs to happen... the block layer already does, apparently. > > > >> If a drive has some quirky behaviour wrt WRITE SAME, then that > >> should be handled in some place where 'quirks' are handled - > >> certainly not in md. > > > > The problem here is that you don't find out ahead of time. > > > > Now, if I understand the issue at hand correctly is that the reporting > > here was actually a Linux bug related to SATA drives behind a SAS > > controller. Martin, am I right? > > Martin, please correct me if I'm wrong, but I think the code > optimistically enabled WRITE_SAME for any drive, except of those on a > sata (libata) controller. So not the drive reported that it can do > WRITE_SAME, but scsi-midlayer did that. Martins patch should improve > that (I still need to test it on our hardware), but I'm not sure if > there won't be some hardware falling through. I'm worried about other unsupported HW, too. Last night I started writing a patch to set the raid1,10 max write same sectors to 0 for inclusion in 3.10 + stable... I'd like to include a mention of Martin's patch/the SATA drives in the commit log. Thanks so much for hunting this down. -- Joe -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
