Mailinglist Archive: opensuse (946 mails)

< Previous Next >
Re: [opensuse] WD Green AV HD: rsync read errors mapping
On 2017-09-03 14:30, Anton Aylward wrote:
On 02/09/17 06:01 AM, Carlos E. R. wrote:
Yes, it is very slow to run.

Yes, but that seems excessive to me.

I realise that there are a number of tunable parameters to the 'badblocks'
command, such as the block size.
And yes, if you have a 4K physical then setting the block size to 4k rather
its default 1K will probably help. Certainly on drives over 2T.

If this is true, it should be automatic.
Next time I'll have to remember this.

But are there any faster methods? What does SMART have to offer?
Surely by now the vendors will have found a use for all that cheap memory and
cpu power they have on the embedded controller boards ???

- one revolution of the disk to write a test pastern to the complete track of
every platter
- the next revolution to read it back, verifying on the fly 'cos the CPU is
so much faster than the disk
- the next revolution to write a different pattern
- step and repeat though the pattern set
- now go to the next track

Of course it is a destructive test, but we knew that to start with.

But badblocks is not destructive.
I don't know exactly how badblocks work.

Typically, I first run a long SMART test, which is a matter of a few
hours. I leave it running during the night.

However, if it finds a single surface error, it stops there. If you want
to find all other possible errors, and locate their LBA address, you
need some tool like badblocks. The idea is to manually overwrite those
sectors to force a remap.

However, you can simply overwrite the entire disk (or partition) with
zeroes. This will cause remap of any bad sector. But you will not know
which, nor how many.

So I prefer to use badblocks. I have also noticed that, in my cases, and
a few others I read about, it failed to find the bad sectors that the
long SMART test said existed. Running smartctl again it also failed to
find those sectors, so the empirical guess is that it can cause "repair"
of sectors transparently.

Cheers / Saludos,

Carlos E. R.
(from 42.2 x86_64 "Malachite" at Telcontar)

< Previous Next >