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 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.
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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org