Mailinglist Archive: opensuse (626 mails)

< Previous Next >
Re: [opensuse] Login weirdness

On Fri, 02 Nov 2018, Liam Proven wrote:
On 02/11/2018 15:57, Carlos E. R. wrote:
This parameter says that there
are a number of sectors that have not being remapped.

To me, that is a danger sign. I don't know exactly what it means or why
but it's worrying.

It means, that the drive was at least _once_ not able to read from
that sector (see the list at the end of 'smartctl -a' output).
Thus, that sector is *pending* to be reallocated, but is not yet.
That happens when you write to that sector. That can be done with

==== man hdparm ====
Writes zeros to the specified sector number. VERY DANGEROUS.
The sector number must be given (base10) after this option.
hdparm will issue a low-level write (completely bypassing the
usual block layer read/write mechanisms) to the specified sec-
tor. This can be used to force a drive to repair a bad sector
(media error).


But that sector will disappear from the "pending/offline
uncorrectable" count but appear as "reallocated" instead (as long as
there are sectors left to be remapped to).

So you can write to that sector number, but it will (physically) be
another sector than originally.

E.g.: sector 10 is reported as bad, you have "pending: 1, offline
uncorrectable: 1, reallocated: 0 and in the test-log (from a smartctl
long test IIRC) shows "LBA_of_first_error: 10".
Say then, you use hdparm to write to that sector. Then you'll get:

"pending: 0, offline unc.: 0, reallocated: 1".

The error-log does not change, but a further test will not fail at
sector 10 again, as that has now been reallocated.

Besides the reallocated-count going up, the error seems to disappear.
Until you run out of sectors to reallocate to and of course, the data
that was on unreadable sectors.

It might be that the disc can scrape the data from the sector by
reading multiple times, but will still mark it as "pending" and
reallocate it when written to.

Concurrent to this, notice that there are several "extended offline"
tests that did not complete, all at the same LBA. I would rewrite that LBA.

I am afraid I must disagree.

You can also run "badblocks" on that disk[...]

OK, I must disagree more.

Care to elaborate as to why? The following?

All hard drives have some bad sectors, it's true. Most develop more
during their operational life, also true.

But they have a pretty large reserved area(maybe 10-15%, it varies a lot
with model and makers don't like to disclose it. An >1% number of
blocks, anyway.) and failed blocks are replaced from the spare blocks.

I doubt that it's that much. Might have been in days long gone.

This remapping is normal and invisible. The OS never knows there was a
read error, it's just switched on the fly.

See above.

Years ago, you could even _hear_ (esp. Seagates) trying to
re-re-re-re-re-read a sector....

Taking _minutes_...

If the OS can see errors, that means that either [a] the disk's
replacement blocks are used up, meaning it has millions of bad blocks,
or [b] the disk is defective in some other way.

smartctl != the OS ;)

In either instance, I would regard that as a failing drive and replace
it immediately.

Agreed. Esp. if the drive is not brand new. Cue the bathtub curve.

Some drives may come/develop some badblocks real fast but then be
stable over years. But if the drive is older, developing badblocks is
a sure warning sign.

Don't waste time trying to rescue it. Get any remaining data off it,
ASAP. Return it for warranty replacement, if possible. If not, send it
for recycling, or take it to bits if you're curious.

Do not waste time trying to fix it, and never use it for anything other
than test purposes again.

Or use it for epheremal stuff, news-spool, DL-caches, whatnot where
you don't really care if you lose it and/or need to reget it.


Once upon a time there was a DOS user who saw Unix, and saw that it was
good. After typing cp on his DOS machine at home, he downloaded GNU's
unix tools ported to DOS and installed them. He rm'd, cp'd, and mv'd
happily for many days, and upon finding elvis, he vi'd and was happy. After
a long day at work (on a Unix box) he came home, started editing a file,
and couldn't figure out why he couldn't suspend vi (w/ ctrl-z) to do
a compile. (By ewt@xxxxxxxxxxxxxxxxxx (Erik Troan)

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups