![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
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. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)