Mailinglist Archive: opensuse (946 mails)

< Previous Next >
Re: [opensuse] WD Green AV HD: rsync read errors mapping
  • From: Knurpht - Gertjan Lettink <knurpht@xxxxxxxxxxxx>
  • Date: Sun, 03 Sep 2017 21:51:48 +0200
  • Message-id: <5637824.ZCR9f1P6cg@knurpht-hp>
Op zondag 3 september 2017 15:36:52 CEST schreef Carlos E. R.:
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 than its default 1K will probably help. Certainly on drives over

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
every platter

- the next revolution to read it back, verifying on the fly 'cos the CPU

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.

In my SystemV Unix days finding badblocks on a 600 MB disk meant call NCR and
have it replaced, then restore a backup from tape. But that took about four to
five hours. The SLA from NCR did simply not allow us to proceed with a disk
that had ( just one or a couple of ) badblocks.

Gertjan Lettink, a.k.a. Knurpht

openSUSE Board Member
openSUSE Forums Team

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

< Previous Next >
Follow Ups