Hi, > Thank you for your response.
Purely selfish. :) I want to know about cabling problems. > Linux pi 4.1.16-v7+ #833 SMP Wed Jan 27 14:32:22 GMT 2016 armv7l GNU/Linux The source code where i find the message text in my Sid kernel is not depending on the CPU architecture. So it is supposed to be in effect on your system. But i riddle why it does not convert 0x2003 to "FAILED". > The RPi2 is a USB 2.0 only device. But yes, I think the drive is 3.0 > capable. The reports about optical drive problems which i have seen during the last year were about USB 2 boxes plugged into USB 3 computer sockets. They are far too few to indicate a general problem. I suspect it is about certain kernels and certain pairings of the two participating USB controllers, maybe even the cables. On the other hand, there are criminal USB power supply contraptions around which in most cases even seem to work. See https://media-cdn.ubuntu-de.org/forum/attachments/00/03/8036213-IMG_0222.JPG https://media-cdn.ubuntu-de.org/forum/attachments/41/03/8037143-51zTbNM27vL._SL1000_.jpg from a german discussion about spurious "host_status 7" errors. I meanwhile suspect something like a dead fruit fly was sticking to the plug. A modern version of the 1947 classic https://en.wikipedia.org/wiki/File:H96566k.jpg > I just hope it is not another HDD failure. Looks like a controller and/or driver problem. The web echo on "UNKNOWN(0x2003)" is suspiciously unhelpful. Lets try google sd "FAILED Result" DID_OK DRIVER_OK Aha. There are kernels which can translate 0x2003 and the commenters are somewhat more qualified. But still no hands-on proposals. > I am hoping the fsck results are reliable. I only tried the "-c" read- > only option. The other was with "-cc" which would also perform a > read/write test. I cannot find "-c" in man fsck of Sid. If it really does read the metadata and the content of data files, then at least your filesystem should be ok for making a backup. (I would not use it for heavy writing before such a backup was made.) If you want to know whether there is a reproducible bad spot, then try whether your disk produces any i/o errors when read flatly. Like dd if=/dev/sda of=/dev/null If you get errors, try whether they occur again if you start reading a few hundred blocks before that address dd if=/dev/sda of=/dev/null skip=...block.number... But i do not really expect a reproducible pattern here. Have a nice day :) Thomas
