Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #163973 > unrolled thread

bad sectors on disk

Back to article view | Back to linux.debian.user

Contents

  bad sectors on disk Ritesh Raj Sarraf <rrs@researchut.com> - 2016-02-09 10:00 +0100
    Re: bad sectors on disk Hans <hans.ullrich@loop.de> - 2016-02-09 10:20 +0100
    Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-09 11:20 +0100
      Re: bad sectors on disk Ritesh Raj Sarraf <rrs@researchut.com> - 2016-02-09 12:00 +0100
        Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-09 13:00 +0100
          Re: bad sectors on disk Eike Lantzsch <zp6cge@gmx.net> - 2016-02-09 13:30 +0100
            Re: bad sectors on disk Eike Lantzsch <zp6cge@gmx.net> - 2016-02-09 13:50 +0100
          Re: bad sectors on disk Ritesh Raj Sarraf <rrs@researchut.com> - 2016-02-10 15:20 +0100
            Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-10 15:40 +0100
        Re: bad sectors on disk jdd <jdd@dodin.org> - 2016-02-09 13:10 +0100
    Re: bad sectors on disk Jonathan Dowland <jmtd@debian.org> - 2016-02-09 16:20 +0100
    Re: bad sectors on disk David Christensen <dpchrist@holgerdanske.com> - 2016-02-09 20:30 +0100
      Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-09 21:00 +0100
    Re: [computers] bad sectors on disk TWS Admin <tws@wilderness.org.au> - 2016-02-11 05:00 +0100
      Re: [computers] bad sectors on disk Joseph Loo <jloo20111002@gmail.com> - 2016-02-11 05:10 +0100
        Re: [computers] bad sectors on disk David Wright <deblis@lionunicorn.co.uk> - 2016-02-12 05:20 +0100
          Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-12 08:50 +0100
            Re: bad sectors on disk Gene Heskett <gheskett@shentel.net> - 2016-02-12 09:30 +0100
              SATA cables David Christensen <dpchrist@holgerdanske.com> - 2016-02-12 18:30 +0100
                Re: SATA cables Ric Moore <wayward4now@gmail.com> - 2016-02-14 01:20 +0100
                  Re: SATA cables Gene Heskett <gheskett@shentel.net> - 2016-02-14 02:00 +0100
                  Re: SATA cables David Christensen <dpchrist@holgerdanske.com> - 2016-02-14 05:40 +0100
                    Re: SATA cables Ric Moore <wayward4now@gmail.com> - 2016-02-14 17:30 +0100
            Re: bad sectors on disk Ritesh Raj Sarraf <rrs@researchut.com> - 2016-02-16 14:40 +0100
              Re: bad sectors on disk Ritesh Raj Sarraf <rrs@researchut.com> - 2016-02-16 15:00 +0100
              Re: bad sectors on disk "Thomas Schmitt" <scdbackup@gmx.net> - 2016-02-16 15:10 +0100
          Re: [computers] bad sectors on disk jdd <jdd@dodin.org> - 2016-02-12 09:30 +0100

Page 1 of 2  [1] 2  Next page →

#163973 — bad sectors on disk

[Multipart message — attachments visible in raw view] — view raw

Hello,

On my RPi2, I saw the following reported by my kernel.

[156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result: hostbyte=0x00
driverbyte=0x00
[156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47 00 00
08 00
[156278.831152] blk_update_request: I/O error, dev sdb, sector 2587886663


This got me worried so I ran an fsck on my drive. Following is the report.

130 pi@pi:~$ sudo fsck -cvkv /dev/sdb1
[sudo] password for pi:
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
Checking for bad blocks (read-only test): done

SEAGATE: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****

       20013 inodes used (0.02%, out of 122101760)
        8944 non-contiguous files (44.7%)
          53 non-contiguous directories (0.3%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 16695/3216/62
   416471936 blocks used (85.28%, out of 488378008)
           0 bad blocks
          63 large files

       17086 regular files
        2885 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
          33 symbolic links (32 fast symbolic links)
           0 sockets
------------
       20004 files
1 pi@pi:~$


>From the report, it says that there are 0 bad blocks. So is this a bug in
e2fsprogs ?


-- 
Ritesh Raj Sarraf
RESEARCHUT -- http://www.researchut.com
"Necessity is the mother of invention"

[toc] | [next] | [standalone]

#163976

> 
> >From the report, it says that there are 0 bad blocks. So is this a bug in
> 
> e2fsprogs ?

Please correct me, if I am wrong. As far as I know, bad sectors are blanked 
out by the hardware itself. If bad sectors are detected, the software tries to 
read and then move the data to a good sectpor and after it sets the sector as 
dead. So this sector does not appear again. 

Maybe this is the reason, why e2fsck only sees and shows good sectors, just 
because it never checks sectors already marked as bad by the hardware itself.

However, I maybe wrong. You should watch this, if more errors appear, think of 
exchanging the drive before it is brain dead.

Best

Hans

[toc] | [prev] | [next] | [standalone]

#163981

Hi,

Ritesh Raj Sarraf's kernel wrote:
> [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
> [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47 00 00 08 00
> [156278.831152] blk_update_request: I/O error, dev sdb, sector 2587886663

This was an attempt to read data from address 0x9a400447,
which would mean your storage medium has a capacity of 1.2 TB at least.

Is this log snippet preceded by lines with "Sense Key" or "Add. Sense" ?


The text "UNKNOWN(0x2003)" is quite popular in the web. But i did not find
further enlightenment yet. (The problem is near enough to my own sports
to make me curious.)

The message part seems to be quite new in the kernel:
  /usr/src/linux-4.1.6/drivers/scsi/scsi_logging.c  line 458
I cannot find it in Jessie's 3.16.
Reason for "UNKNOWN" is that scsi_mlreturn_string() in
drivers/scsi/constants.c did not find 0x2003 in scsi_mlreturn_arr.
This is riddling, because in include/scsi/scsi.h i see
  #define FAILED          0x2003
which i see mentioned in drivers/scsi/constants.c as member of
scsi_mlreturn_arr[]:
  #define scsi_mlreturn_name(result)      { result, #result }
  ...
        scsi_mlreturn_name(FAILED),

Looks like something with the macro magic of scsi_mlreturn_name()
does not work as expected.
  https://gcc.gnu.org/onlinedocs/cpp/Stringification.html
Or scsi_mlreturn_string() does not search far enough. But the
many definitions of ARRAY_SIZE in kernel headers look ok to my
userlander eyes.

What kernel version exactly are you using ?

-------------------------------------------------------------------

Whatever, "FAILED" instead of "UNKNOWN(0x2003)" will not help much
to find the reason for the problem.

If it happened with an optical drive, i'd say it is a volatile hardware
error in one of the participating bus controllers or in their cabling.
(The current main suspect for controller problems is USB 3.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#163987

[Multipart message — attachments visible in raw view] — view raw

Hello Thomas,

Thank you for your response.

On Tue, 2016-02-09 at 11:17 +0100, Thomas Schmitt wrote:
> Hi,
> 
> Ritesh Raj Sarraf's kernel wrote:
> > [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result:
> > hostbyte=0x00 driverbyte=0x00
> > [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04
> > 47 00 00 08 00
> > [156278.831152] blk_update_request: I/O error, dev sdb, sector
> > 2587886663
> 
> This was an attempt to read data from address 0x9a400447,
> which would mean your storage medium has a capacity of 1.2 TB at
> least.

Yes. This is a 2 TB Seagate drive.

[    4.247833] scsi 0:0:0:0: Direct-Access     Seagate  FA GoFlex
Desk   0155 PQ: 0 ANSI: 4
[    4.253080] sd 0:0:0:0: [sda] 3907029167 512-byte logical blocks:
(2.00 TB/1.81 TiB)
[    4.253598] sd 0:0:0:0: [sda] Write Protect is off
[    4.253613] sd 0:0:0:0: [sda] Mode Sense: 1c 00 00 00
[    4.254114] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO
 or FUA
[    4.273477] bcm2708_rng_init=b3a1c000
[    4.287442]  sda: sda1
[    4.298911] sd 0:0:0:0: [sda] Attached SCSI disk


> 
> Is this log snippet preceded by lines with "Sense Key" or "Add.
> Sense" ?
> 

No. Those were the only lines reported. I recently lost another drive
that was attached to the same Raspberry Pi. But that one had a FAT file
system.


> 
> The text "UNKNOWN(0x2003)" is quite popular in the web. But i did not
> find
> further enlightenment yet. (The problem is near enough to my own
> sports
> to make me curious.)
> 
> The message part seems to be quite new in the kernel:
>   /usr/src/linux-4.1.6/drivers/scsi/scsi_logging.c  line 458
> I cannot find it in Jessie's 3.16.
> Reason for "UNKNOWN" is that scsi_mlreturn_string() in
> drivers/scsi/constants.c did not find 0x2003 in scsi_mlreturn_arr.
> This is riddling, because in include/scsi/scsi.h i see
>   #define FAILED          0x2003
> which i see mentioned in drivers/scsi/constants.c as member of
> scsi_mlreturn_arr[]:
>   #define scsi_mlreturn_name(result)      { result, #result }
>   ...
>         scsi_mlreturn_name(FAILED),
> 
> Looks like something with the macro magic of scsi_mlreturn_name()
> does not work as expected.
>   https://gcc.gnu.org/onlinedocs/cpp/Stringification.html
> Or scsi_mlreturn_string() does not search far enough. But the
> many definitions of ARRAY_SIZE in kernel headers look ok to my
> userlander eyes.
> 
> What kernel version exactly are you using ?
> 

I am on a fairly recent kernel.

pi@pi:~$ uname -a
Linux pi 4.1.16-v7+ #833 SMP Wed Jan 27 14:32:22 GMT 2016 armv7l
GNU/Linux


> -------------------------------------------------------------------
> 
> Whatever, "FAILED" instead of "UNKNOWN(0x2003)" will not help much
> to find the reason for the problem.
> 
> If it happened with an optical drive, i'd say it is a volatile
> hardware
> error in one of the participating bus controllers or in their
> cabling.
> (The current main suspect for controller problems is USB 3.)
> 
> 
> Have a nice day :)
> 
> Thomas
> 

The RPi2 is a USB 2.0 only device. But yes, I think the drive is 3.0
capable.

Bus 001 Device 004: ID 0bc2:5071 Seagate RSS LLC 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bc2 Seagate RSS LLC
  idProduct          0x5071 
  bcdDevice            1.55
  iManufacturer           1 Seagate
  iProduct                2 FA GoFlex Desk
  iSerial                 3 NA0K1JZA
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0


I just hope it is not another HDD failure.


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.


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[toc] | [prev] | [next] | [standalone]

#163988

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

[toc] | [prev] | [next] | [standalone]

#163991

Hi Ritesh Raj Sarraf

Just a thought - my two cents:

On Tuesday 09 February 2016 12:53:04 Thomas Schmitt wrote:
> 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.

Are you copying or moving files from or to your USB-HDD via the network?
RPis share the same USB controller for the network chip and for the USB-ports.
My experience with RPis is that heavy network traffic makes the I/O over the 
USB-ports to and from HDDs very shaky. I even lost a HDD that way.
If you want some sort of a NAS then ditch the RPi. You will be better off with 
a Cubietruck if you want to stick to ARM-architecture or a PC-Engines ALIX 
(i386) or a PC-Engines APU if you prefer amd64 and want more memory.

All the best
Eike

> 
> 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.JP
> G
> 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.
I second that - see above.
> 
> 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

-- 
Eike Lantzsch ZP6CGE
Agencia Shopping del Sol
Casilla de Correo 13005
1749 Asuncion / Paraguay
Land-line: +595-21-553984
Cell-phone: +595-971-696909
Skype: eikelan

[toc] | [prev] | [next] | [standalone]

#163992

On Tuesday 09 February 2016 09:25:40 Eike Lantzsch wrote:
> Hi Ritesh Raj Sarraf
> 
> Just a thought - my two cents:
> 
> On Tuesday 09 February 2016 12:53:04 Thomas Schmitt wrote:
> > 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.
> 
> Are you copying or moving files from or to your USB-HDD via the network?
> RPis share the same USB controller for the network chip and for the
> USB-ports. My experience with RPis is that heavy network traffic makes the
> I/O over the USB-ports to and from HDDs very shaky. I even lost a HDD that
> way. If you want some sort of a NAS then ditch the RPi. You will be better
> off with a Cubietruck if you want to stick to ARM-architecture or a
> PC-Engines ALIX (i386) or a PC-Engines APU if you prefer amd64 and want
> more memory.

I should have mentioned:
Cubietruck and APU: connect HDD w/ SATA
ALIX: only parallel port for HDD
> 
> All the best
> Eike
[snip]

[toc] | [prev] | [next] | [standalone]

#164029

[Multipart message — attachments visible in raw view] — view raw

Hello Thomas,

On Tue, 2016-02-09 at 12:53 +0100, Thomas Schmitt wrote:
> 
> > 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".
> 
> 

I'm now updating my kernel to see if there are any improvements, which
I doubt because there's hardly any change in the repo.

But I've filed a bug to keep the RPi guy informed.

https://github.com/Hexxeh/rpi-firmware/issues/103


> 
> > 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've seen the same message again, today. but at different locations.

[62711.477903] sd 0:0:0:0: [sda] UNKNOWN(0x2003) Result: hostbyte=0x00
driverbyte=0x00
[62711.485701] sd 0:0:0:0: [sda] CDB: opcode=0x28 28 00 9d 40 01 47 00
00 08 00
[62711.492910] blk_update_request: I/O error, dev sda, sector
2638217543
[84370.313684] sd 0:0:0:0: [sda] UNKNOWN(0x2003) Result: hostbyte=0x00
driverbyte=0x00
[84370.321532] sd 0:0:0:0: [sda] CDB: opcode=0x28 28 00 a1 40 01 47 00
00 08 00
[84370.328721] blk_update_request: I/O error, dev sda, sector
2705326407

And about your last question, No, apart from these, there are no other
message about any sense code.


> > 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. 
> 

Run the command `man fsck.ext4`

Just `man fsck` takes you to the outdated/wrong util-linux manpage.


> 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.)
> 

Yes. I guess I'll do the same. The other spare one has enough space. So
I'm going to backup everything and try your verification example of dd
below.

Thanks again.


> 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.
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[toc] | [prev] | [next] | [standalone]

#164030

Hi,

Ritesh Raj Sarraf wrote:
> I've seen the same message again, today. but at different locations.
> [...] there are no other message about any sense code.

One point for the theory of volatile bus problems.
The disk itself seems happy. Maybe its bus controller is not.

Did i already mention that USB 3 drop-outs are fashionable currently ?
(But too rare to be a general disease.)


> > I cannot find "-c" in man fsck of Sid. 
> Run the command `man fsck.ext4`

Aha.
"-c [...] read-only  scan  of  the device in order to find any bad blocks.
    If any bad blocks are found, they are added  to  the  bad  block inode"

If the problem is not reproducible on the particular blocks, it would
be a waste of good file content if 0x2003 incidents would cause blocks
to be marked bad.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#163990

Le 09/02/2016 11:54, Ritesh Raj Sarraf a écrit :

> 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.
>
>
try

http://dodin.info/wiki/pmwiki.php?n=Doc.TesterUnDisqueDur

it's in french, but the command lines are pretty clear

jdd

[toc] | [prev] | [next] | [standalone]

#163995

It would be interesting to check your drive's SMART data to see if that has
reported any errors. You might be able to do this with smartctl from the
smartmontools package, depending on which USB bridge you have. I recently
uploaded a new version of the package to unstable, but I do not know if/when
that might appear in Raspbian (which I presume you are using)

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#164001

On 02/09/2016 12:57 AM, Ritesh Raj Sarraf wrote:
> On my RPi2, I saw the following reported by my kernel.
...
> This got me worried so I ran an fsck on my drive. Following is the report.
...
> SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****
...

I suggest that you download Seagate's Seatools for DOS (bootable ISO 
image), burn it to disc, and run it:

     http://www.seagate.com/support/downloads/seatools/


For machines that don't have an optical drive, this page explains how to 
convert a bootable CD ISO image into a bootable hybrid ISO/USB image 
that can be burned to a USB flash drive and booted on machines that 
support such:

     https://www.turnkeylinux.org/blog/iso2usb


As an aside, I have Seagate, Western Digital, Intel, Samsung, Maxtor, 
and possibly other brands of HDD/ SSD.  While these manufacturers seem 
to provide utilities that run on Windows, Seagate is the only vendor I 
know of that still provides their tool as a stand-alone bootable ISO. 
In years past, some vendors offered bootable floppy disk images, 
bootable floppy disk creators, and/or files that could be copied to a 
bootable floppy made with Windows.  Such stand-alone utilities are 
invaluable for troubleshooting and/or repair.  Does anyone have links to 
such tools?  I'm especially interested in Western Digital DLG 5.04f. 
I'm also looking for a HOWTO for converting a bootable floppy image to a 
bootable USB flash drive image.


David

[toc] | [prev] | [next] | [standalone]

#164002

Hi,

David Christensen wrote:
> http://www.seagate.com/support/downloads/seatools/
> convert a bootable CD ISO image into a bootable hybrid ISO/USB image
> https://www.turnkeylinux.org/blog/iso2usb

This will not work, i fear, because the ISO is not bootable via an
isohybrid capable ISOLINUX boot image.

>From the start of the El Torito boot image in SeaToolsDOS223ALL.ISO:
  Bootable CD Wizard v1.50Z
  Copyright (c)2004 by reanimatolog. http://bootcd.narod.ru


(This statement from blog/iso2usb is plain wrong:
 "The isohybrid tool in the syslinux package will convert ISO images
  into a USB flash drive compatible format"
isohybrid writes an MBR and partition tables into the System Area
of the ISO, so that boot firmware can find the boot loader if the ISO
is presented on HDD. The ISO 9660 filesystem does not get converted.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#164049 — Re: [computers] bad sectors on disk

[Multipart message — attachments visible in raw view] — view raw

Please remove julius.roberts@wildernes.org.au from this list, he's no
longer working with us.

thanks,

the Wilderness society

On 9 February 2016 at 19:57, Ritesh Raj Sarraf <rrs@researchut.com> wrote:

> Hello,
>
> On my RPi2, I saw the following reported by my kernel.
>
> [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result: hostbyte=0x00
> driverbyte=0x00
> [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47 00 00
> 08 00
> [156278.831152] blk_update_request: I/O error, dev sdb, sector 2587886663
>
>
> This got me worried so I ran an fsck on my drive. Following is the report.
>
> 130 pi@pi:~$ sudo fsck -cvkv /dev/sdb1
> [sudo] password for pi:
> fsck from util-linux 2.25.2
> e2fsck 1.42.12 (29-Aug-2014)
> Checking for bad blocks (read-only test): done
>
> SEAGATE: Updating bad block inode.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
>
> SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****
>
>        20013 inodes used (0.02%, out of 122101760)
>         8944 non-contiguous files (44.7%)
>           53 non-contiguous directories (0.3%)
>              # of inodes with ind/dind/tind blocks: 0/0/0
>              Extent depth histogram: 16695/3216/62
>    416471936 blocks used (85.28%, out of 488378008)
>            0 bad blocks
>           63 large files
>
>        17086 regular files
>         2885 directories
>            0 character device files
>            0 block device files
>            0 fifos
>            0 links
>           33 symbolic links (32 fast symbolic links)
>            0 sockets
> ------------
>        20004 files
> 1 pi@pi:~$
>
>
> From the report, it says that there are 0 bad blocks. So is this a bug in
> e2fsprogs ?
>
>
> --
> Ritesh Raj Sarraf
> RESEARCHUT -- http://www.researchut.com
> "Necessity is the mother of invention"
>

[toc] | [prev] | [next] | [standalone]

#164050 — Re: [computers] bad sectors on disk

On 02/10/2016 07:35 PM, TWS Admin wrote:
> Please remove julius.roberts@wildernes.org.au
> <mailto:julius.roberts@wildernes.org.au> from this list, he's no longer
> working with us.
> 
> thanks,
> 
> the Wilderness society
> 
> On 9 February 2016 at 19:57, Ritesh Raj Sarraf <rrs@researchut.com
> <mailto:rrs@researchut.com>> wrote:
> 
>     Hello,
> 
>     On my RPi2, I saw the following reported by my kernel.
> 
>     [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result:
>     hostbyte=0x00 driverbyte=0x00
>     [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47
>     00 00 08 00
>     [156278.831152] blk_update_request: I/O error, dev sdb, sector
>     2587886663
> 
> 
>     This got me worried so I ran an fsck on my drive. Following is the
>     report.
> 
>     130 pi@pi:~$ sudo fsck -cvkv /dev/sdb1 
>     [sudo] password for pi: 
>     fsck from util-linux 2.25.2
>     e2fsck 1.42.12 (29-Aug-2014)
>     Checking for bad blocks (read-only test): done                      
>                               
>     SEAGATE: Updating bad block inode.
>     Pass 1: Checking inodes, blocks, and sizes
>     Pass 2: Checking directory structure
>     Pass 3: Checking directory connectivity
>     Pass 4: Checking reference counts
>     Pass 5: Checking group summary information
> 
>     SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****
> 
>            20013 inodes used (0.02%, out of 122101760)
>             8944 non-contiguous files (44.7%)
>               53 non-contiguous directories (0.3%)
>                  # of inodes with ind/dind/tind blocks: 0/0/0
>                  Extent depth histogram: 16695/3216/62
>        416471936 blocks used (85.28%, out of 488378008)
>                0 bad blocks
>               63 large files
> 
>            17086 regular files
>             2885 directories
>                0 character device files
>                0 block device files
>                0 fifos
>                0 links
>               33 symbolic links (32 fast symbolic links)
>                0 sockets
>     ------------
>            20004 files
>     1 pi@pi:~$ 
> 
> 
>     From the report, it says that there are 0 bad blocks. So is this a
>     bug in e2fsprogs ?
> 
> 
>     -- 
>     Ritesh Raj Sarraf
>     RESEARCHUT -- http://www.researchut.com
>     "Necessity is the mother of invention"
> 
> 
fsck checks primarily a directory structure not the hard drives. you
might want to try

badblocks -svn /dev/sdb

Like always, backup your drive before you do this.

-- 
Joseph Loo
jloo@acm.org

[toc] | [prev] | [next] | [standalone]

#164094 — Re: [computers] bad sectors on disk

On Wed 10 Feb 2016 at 20:05:39 (-0800), Joseph Loo wrote:

> > On 9 February 2016 at 19:57, Ritesh Raj Sarraf <rrs@researchut.com wrote:

> >     On my RPi2, I saw the following reported by my kernel.
> > 
> >     [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result:
> >     hostbyte=0x00 driverbyte=0x00
> >     [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47
> >     00 00 08 00
> >     [156278.831152] blk_update_request: I/O error, dev sdb, sector
> >     2587886663
> > 
> >     This got me worried so I ran an fsck on my drive. Following is the
> >     report.
> > 
> >     130 pi@pi:~$ sudo fsck -cvkv /dev/sdb1 
> >     [sudo] password for pi: 
> >     fsck from util-linux 2.25.2
> >     e2fsck 1.42.12 (29-Aug-2014)
> >     Checking for bad blocks (read-only test): done 
> > 
> >     SEAGATE: Updating bad block inode.
> >     Pass 1: Checking inodes, blocks, and sizes
> >     Pass 2: Checking directory structure
> >     Pass 3: Checking directory connectivity
> >     Pass 4: Checking reference counts
> >     Pass 5: Checking group summary information
> > 
> >     SEAGATE: ***** FILE SYSTEM WAS MODIFIED *****
> > 
> >            20013 inodes used (0.02%, out of 122101760)
> >             8944 non-contiguous files (44.7%)
> >               53 non-contiguous directories (0.3%)
> >                  # of inodes with ind/dind/tind blocks: 0/0/0
> >                  Extent depth histogram: 16695/3216/62
> >        416471936 blocks used (85.28%, out of 488378008)
> >                0 bad blocks
> >               63 large files
> > 
> >            17086 regular files
> >             2885 directories
> >                0 character device files
> >                0 block device files
> >                0 fifos
> >                0 links
> >               33 symbolic links (32 fast symbolic links)
> >                0 sockets
> >     ------------
> >            20004 files
> >     1 pi@pi:~$ 
> > 
> >     From the report, it says that there are 0 bad blocks. So is this a
> >     bug in e2fsprogs ?

Does one I/O error mean that you have a bad block necessarily?

> fsck checks primarily a directory structure not the hard drives. you
> might want to try
> 
> badblocks -svn /dev/sdb
> 
> Like always, backup your drive before you do this.

Reading   man badblocks:

"Important note: If the output of badblocks is going to be fed to the
e2fsck or mke2fs programs, it is important that the block size is
properly specified, since the block numbers which are generated are
very dependent on the block size in use by the filesystem. For this
reason, it is strongly recommended that users not run badblocks
directly, but rather use the -c option of the e2fsck and mke2fs
programs."

I can't see any point in running badblocks and not putting any bad
blocks that it finds into the badblock inode. So running

sudo fsck -cvkv /dev/sdb1

seemed like a sensible course of action to me, even if it failed to
find any bad blocks. Here's an example of what can/may/should happen:

Script started on Tue 09 Feb 2016 08:58:13 AM CST
# e2fsck -c -k -v /dev/sda3
e2fsck 1.42.5 (29-Jul-2012)
Checking for bad blocks (read-only test):
0.00% done, 0:00 elapsed. (0/0/0 errors)
[... loads of progress lines ...]
99.98% done, 55:13 elapsed. (1/0/0 errors)
...........................................done
john03: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

john03: ***** FILE SYSTEM WAS MODIFIED *****

       73793 inodes used (2.63%, out of 2809856)
       23325 non-contiguous files (31.6%)
          75 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 22365/1027/0
     9234305 blocks used (82.22%, out of 11231443)
           1 bad block
           1 large file

       68480 regular files
        4853 directories
           0 character device files
           0 block device files
           0 fifos
           5 links
         451 symbolic links (450 fast symbolic links)
           0 sockets
------------
       73789 files
# exit
Script done on Tue 09 Feb 2016 09:59:18 AM CST

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#164098

Hi,

Ritesh Raj Sarraf wrote:
> > >     From the report, it says that there are 0 bad blocks. So is this a
> > >     bug in e2fsprogs ?

David Wright wrote:
> Does one I/O error mean that you have a bad block necessarily?

I personally do not believe in a bad spot here, but in a bad bus.
Throwing out blocks which fall victim to a bus glitch would then
unnecessarily kill files and reduce disk capacity.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#164100

On Friday 12 February 2016 02:42:19 Thomas Schmitt wrote:

> Hi,
>
> Ritesh Raj Sarraf wrote:
> > > >     From the report, it says that there are 0 bad blocks. So is
> > > > this a bug in e2fsprogs ?
>
> David Wright wrote:
> > Does one I/O error mean that you have a bad block necessarily?
>
> I personally do not believe in a bad spot here, but in a bad bus.
> Throwing out blocks which fall victim to a bus glitch would then
> unnecessarily kill files and reduce disk capacity.
>
Is the OP talking about a sata interfaced device?  If so, is the sata 
cable a semi-reddish, tending toward hints of magenta color?  And more 
than 1 year old? 

That particular color of sata cables has a very poor record of 
satisfactory service at my location, and in my travels I have a tendency 
to collect spare sata cables that are NOT that "hot red' color. When a 
cable gets flaky, it gets replaced with a tan one or a black one and 
that seems to be the best long term fix.

As a CET*, with a long term relationship with cables that used that 
particular plastic dye to color one of a multiconductor cable, such as 
in the microphone cable of a CB Radio, first encountered here in the 
later 60's as radios from the J.A.Pan company started flooding the US 
market, it was this 'hot red' colored wire in a mic cable that always 
broke, and you could cut it back 2 cm figuring on cutting off the 
fraction of that which had failed and resoldering the connector to fresh 
wire.  Except when I saw that color. After a year or 2, there was no 
wire remaining in that tubing, just a reddish copper dust!  Whatever 
gave it that color, literally dissolved, or oxidized the copper in 3 
years time at the maximum.

Sata cables, having even smaller gage conductors, it stands to reason 
would fail even faster and that has been my experience.

A quick test, pull the side off the box, put a tail on the messages 
logfile, then take a stick about the size of a lead pencil, and prod 
each such cable, moving it an inch or so.  If the log explodes with sata 
reset messages, you have one of those time bombs.  Replace it, with one 
that is not that "hot red" color.

*CET=Certified Electronics Technician.

> Have a nice day :)
>
> Thomas

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#164115 — SATA cables

On 02/12/2016 12:24 AM, Gene Heskett wrote:
> is the sata cable a semi-reddish [?]...
> That particular color of sata cables has a very poor record of
> satisfactory service at my location,...
 > microphone cable of a CB Radio, ...
 > 'hot red' colored wire in a mic cable that always broke, ...
 > After a year or 2, there was no wire remaining in that tubing, just a
 > reddish copper dust!

Wow.  Somebody didn't understand chemistry/ metallurgy.  I'd suspect the 
copper before the insulation (or the jacket), but only a chemical 
assessment would tell.


Most of my SATA cables are red, simply because that's what came in the 
box with a motherboard, HBA/ RAID card, mobile dock, HDD/ SSD, etc..


I don't recall bus problems with SATA I.


The problems started when SATA II came out and the speed doubled. 
Things got worse with SATA III.  I use mobile docks, and they add yet 
another point of failure.


I've had recall several situations over the years where some cables 
worked and others did not. Usually, the failing cables had loose 
connectors.  Those cables went into the recycle pile.


STFW some sites say all SATA cables are the same.  Looking at my 
collection, I don't see any SATA I/II/III, MHz, or Gbps markings.  So, 
I've starting serializing them with a Sharpie and keeping a log.  We'll 
see if that helps going forward.


Cables sold as "SATA III" command a premium price.  The last time I 
shopped for them, they all had retaining clips.  I hate clips -- they 
tend to get stuck once the cable is connected, and I have to break the 
cable connector to disconnect the cable.


Does anyone have recommendations for ~20" SATA III cables with straight 
connectors and no clips?


David

[toc] | [prev] | [next] | [standalone]

#164150 — Re: SATA cables

On 02/12/2016 12:21 PM, David Christensen wrote:
> On 02/12/2016 12:24 AM, Gene Heskett wrote:
...
>  > 'hot red' colored wire in a mic cable that always broke, ...
>  > After a year or 2, there was no wire remaining in that tubing, just a
>  > reddish copper dust!
>
> Wow.  Somebody didn't understand chemistry/ metallurgy.  I'd suspect the
> copper before the insulation (or the jacket), but only a chemical
> assessment would tell.

I personally know that Gene hails back to the days when real men used 
soldering irons in the TV broadcast industry. On another list Gene made 
the same claim about 5 years ago. All of my drives were acting flakey, 
so I took his hint and replaced the cables with black ones. No more 
problems. As far as the chemistry goes, if the red dye contained an 
oxidizer, then the heat from the amperage flowing in the cable would 
cause gassing and a faster oxidation rate. Copper does oxidize quite 
readily. I spent 26 years in the chemical industry and a 20 degree rise 
above room temperature would cause some of our caustics to eat 
everything that attempted to pump them. So, while someone might not know 
chemistry/metallurgy, it might not be Gene. Ric

-- 
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web