On 6/20/2014 4:36 AM, Hans van Kranenburg wrote:
I really want to understand what this message means and who generated it. If I assume it's the NetApp filer that returns this data when issuing an UNMAP command, I wonder why. Could any of you NetApp folks shed some light on when and how ontap 8.1.2 7-Mode might ever send this error back? This could help finding a test case which will trigger this error, and to find out why it does not occur in a different situation that seems to be identical. The whole error still does not make a huge amount of sense to me. Why would my NetApp system return an error which I only would expect to see when using a CD-ROM drive or some USB removable device? It's not like all disks suddenly vanished from my FAS and disk shelves, like ejecting a CD drive. :-) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740701
So firstly, the question arises why your kernel marked all paths as failed when you hit this error. This actually resembles the old Linux behavior where for a device error such as a MEDIUM ERROR, it gets retried on all paths available to the LUN, all which result in the same error, and hence all paths get marked as failed. This was addressed with the upstream patch at http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=63583cca745f440167bf27877182dc13e19d4bcf, where more fine-grained error handling is now available. With this, device errors such as MEDIUM ERROR are no longer retried since it treats such errors as permanent errors. That makes me suspect your kernel is already missing some of the key patches from the upstream kernel in context with this error handling. And given that UNMAP has also been a relatively new feature which underwent several upstream revisions to get to the current stable state, it would be prudent for you to check if your kernel is up-to-date with its SCSI & UNMAP handling.
That said, it is indeed strange that you hit a MEDIUM ERROR in the first place, when using UNMAP. As described above, that's a device error. So does this fail even for other commands such as a regular write (you could try this with dd) or even a simple TUR command (like say using sg_turs -v /dev/mpathX)?
-Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org