[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bad sectors on disk



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


Reply to: