Mailinglist Archive: opensuse (4570 mails)
| < Previous | Next > |
Re: [SLE] SATA not working with 9.3, but works with 9.1 (right format)
- From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
- Date: Mon, 7 Nov 2005 20:49:49 +0000 (UTC)
- Message-id: <Pine.LNX.4.61.0511072042510.10443@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Monday 2005-11-07 at 00:25 -0700, Carlos F Lange wrote:
> > > boots fine, despite the couple of bad blocks.
> >
> > Having badblocks in a HD is absolutely normal. In fact, it is practically
> > impossible to have defect free hard disks. Therefore, they have a number
> > of sectors reserved by the manufacturer for replacing bad blocks. When the
> > disk tries to write on a bad block, it automatically writes the data on
> > one of the reserved blocks, and from then on, every request for that
> > sector is instead maped to the new one. This is done transparently to the
> > OS, but it can be dissabled (hdparm).
>
> I thought this was a sign that a hard disk was going bad.
> Actually resierfsck has a comment accompanying the bad block
> message saying something to the tune of "it is not worth risking
> your data with this hard disk".
Yes, it is a sign of age, but not always. My rule of thumb is to worry
when the number of bad sectors continues increasing, and not if it
stabilizes.
For example, if I gave a hard blow with the hand on the table, and the
HD complains of bad sectors, then I would change that HD _fast_. :-P
> > One of the three Seagate disks on this system developped bad blocks some
> > years ago, and is still working, 10000 working hours later. Not a problem.
>
> OK, this gives me a bit of comfort, but it still doesn't help me with the
> second SATA disk I purchased. Why is 9.3 hanging on that disk, when
> 9.1 has no problem with it? Anything else I can try to make it work?
I don't know.
Who is giving that error message ("Searching for info file"), grub? I just
searched the manual, but couldn't find it. But I think you mean it is a
kernel message: it has a problem with iterrupt request #11, that went
unhandled, then crashes.
What kernel are you using, the last one? I had problems with
"2.6.11.4-21.9" crashing, and had to revert to 2.6.11.4-21.8. My error was
"kernel: hdb dma_timer_expiry: dma status= 0x64", and I'm not the only one
having that problem with that particular kernel. Something they changed in
the HD handling.
>
> > Simply having some bad blocks is not enough reason to throw away a disk.
> > Just force a write on those two bad sectors.
>
> I heard this before, but I have no idea how to write on those blocks.
> If I know block and sector numbers from reiserfsck, how can I direct
> a write command to those blocks?
With dd - I'm not sure of the exact command now, I'd have to dig the
manual. Or overwrite the whole disk with zeros, to be on
overkill^H^H..^Hsafe mode. O simply delete the files affected, and wait
till the space gets overwritten... but I don't like that idea.
Reiserfs is not happy handling bad blocks. Or was, I think they changed
things in that respect. Older/traditional filesystems simply marked the
sector as bad, and went on working. Reiserfs instead relied on the HD
firmware remapping feature (also called "defect management feature"). But
as I said, this has changed, although I haven't tested it.
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFDb7intTMYHG2NR9URApLzAJ9slWjy6dsWYo18y6Hca5q423cB1gCeI2To
O2z8LNC+Zwn199aLosU93N0=
=054W
-----END PGP SIGNATURE-----
Hash: SHA1
The Monday 2005-11-07 at 00:25 -0700, Carlos F Lange wrote:
> > > boots fine, despite the couple of bad blocks.
> >
> > Having badblocks in a HD is absolutely normal. In fact, it is practically
> > impossible to have defect free hard disks. Therefore, they have a number
> > of sectors reserved by the manufacturer for replacing bad blocks. When the
> > disk tries to write on a bad block, it automatically writes the data on
> > one of the reserved blocks, and from then on, every request for that
> > sector is instead maped to the new one. This is done transparently to the
> > OS, but it can be dissabled (hdparm).
>
> I thought this was a sign that a hard disk was going bad.
> Actually resierfsck has a comment accompanying the bad block
> message saying something to the tune of "it is not worth risking
> your data with this hard disk".
Yes, it is a sign of age, but not always. My rule of thumb is to worry
when the number of bad sectors continues increasing, and not if it
stabilizes.
For example, if I gave a hard blow with the hand on the table, and the
HD complains of bad sectors, then I would change that HD _fast_. :-P
> > One of the three Seagate disks on this system developped bad blocks some
> > years ago, and is still working, 10000 working hours later. Not a problem.
>
> OK, this gives me a bit of comfort, but it still doesn't help me with the
> second SATA disk I purchased. Why is 9.3 hanging on that disk, when
> 9.1 has no problem with it? Anything else I can try to make it work?
I don't know.
Who is giving that error message ("Searching for info file"), grub? I just
searched the manual, but couldn't find it. But I think you mean it is a
kernel message: it has a problem with iterrupt request #11, that went
unhandled, then crashes.
What kernel are you using, the last one? I had problems with
"2.6.11.4-21.9" crashing, and had to revert to 2.6.11.4-21.8. My error was
"kernel: hdb dma_timer_expiry: dma status= 0x64", and I'm not the only one
having that problem with that particular kernel. Something they changed in
the HD handling.
>
> > Simply having some bad blocks is not enough reason to throw away a disk.
> > Just force a write on those two bad sectors.
>
> I heard this before, but I have no idea how to write on those blocks.
> If I know block and sector numbers from reiserfsck, how can I direct
> a write command to those blocks?
With dd - I'm not sure of the exact command now, I'd have to dig the
manual. Or overwrite the whole disk with zeros, to be on
overkill^H^H..^Hsafe mode. O simply delete the files affected, and wait
till the space gets overwritten... but I don't like that idea.
Reiserfs is not happy handling bad blocks. Or was, I think they changed
things in that respect. Older/traditional filesystems simply marked the
sector as bad, and went on working. Reiserfs instead relied on the HD
firmware remapping feature (also called "defect management feature"). But
as I said, this has changed, although I haven't tested it.
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFDb7intTMYHG2NR9URApLzAJ9slWjy6dsWYo18y6Hca5q423cB1gCeI2To
O2z8LNC+Zwn199aLosU93N0=
=054W
-----END PGP SIGNATURE-----
| < Previous | Next > |