Hi Folks,

I have been getting into the world of Linux, partly because it has some quite good tools for dealing with DR. I have been slowly find ways to do things that I used to do in Windows in Linux.

One of these is the surface test of a hard disk. In WIndows I used to use Partition Table Doctor, which is a farily generic windows based surface tester among other things.

The other day I used badblock on a drive that Partition table doctor had told me had a bad sector, but badblocks failed to find it.

This has got me puzzled. Anyone able to shed any light on why this might be?

Admittadly the drive only had 1 bad block, but shouldnt the results be the same?

Cheers in advance,

-Al

hi,

if your data is NOT important, use badblocks in this way: badblocks -vvw /dev/[device] (not partiton!)

If your data IS important, you can use only the readonly scan test like this: badblocks -vv /dev/[device] (not partiton!)

If the drive have one actually not readable sector, the second step will find it.
If you drive have no data, the first test can re-allocate the all defective sectors, wich can hide the drive into the Grown defect list....

Janos

So badblocks will not detect remapped sectors?

I tried the first read only test, but am still at a loss as to why Windows says Yes and Linux says No...weird.

-Al

can you send a screenshot from windows, and post the report of this from linux:
smartctl -a /dev/[DEVICE]

Thanks,
Janos

Bugger, I havent got the disk anymore. What I might do is try to reproduce the (inconsistent) results with some other hard disks I have lying around and then, it its still different I will post results here.

Its got me curious, and when I get the time I want to do some further experimenting

Will let ya know and thanks for the offer.

-Al

Well I found another disk with a bad sector and tested the surface again in Windows. The bad sector showed up fine.

I went to test with badblocks, this time something different happened - badblocks hung. I did this 3 times in badblocks and hung each time at the same place! It was of course only the read test.

Is there a way around this?

TIA

-Al

badblocks uses the kernel's internal driver for the interface.
These drivers sometimes have bugs too, looks like this is the one of these.
So, the problem is not inside the badblocks, but in the IDE/SATA driver wich you are using.
Wich chipsed or interface card what you are using?

I am always tests the repaired HDD's with badblock (+own script) but never have any issue with this.
(I use SIL680/Intel/promise chipset all the time.)

But i need to note, i always diagnose the HDD with MHDD before runs the badblocks.
And maybe this is why i always prevent the failure.

Janos

Good point Janos. I was using a USB bridge. Will try it straight on the controller. The aim for me here is to be able to do certan things in Linux that I am used to doing in windows, and having confidence in the results.

Cheers

-Al

Hi Janos,

You were right, it was a driver issue and connecting to a controller direct fixed the hanging problem.

badblocks did detect 73 badblocks, yet Partition Table Doctor in Windows only detected 1.

I think that the two peices of software are addressing the disk in different ways when they report badblocks/sectors. I say this because badblocks detected a sequential list of badblocks between:
2243832-22438399

Yet Partition Table Doctor reported one bad sector @ 44876663.

Would it be that one is using CHS and one is using LBA?

The disk is a Seagate ST960812A which has a CHS of 16383/16/63.

Still a bit confused trying to reconcile the results, but getting closer. I would be keen to hear your thoughts Janos.

Cheers

-Al

more details:

PTD uses LBA, wich is in 512 byte blocks.
badblocks counts in Kbytes, (1024) blocks, this is why the half is the result. (No CHS)
And because the linux kernel handles the hdd, not the badblocks, there is one more point:
The default block size in kernel's block layer is 4KB (= 8 LBA sectors), and badblocks can't override this option.
But maybe you can more fine tune the result, if you set the blockdev layer's readahead for the device:
blockdev --setra 0 /dev/[device]

ps: USB driver is slow, but never have issues for me.
Times changing...

Janos

Thats helpful.Thanks.

I still cant help feeling that badblocks is better tool than PTD. Look at how many blocks badblocks reported as bad, versus PTD (73 vs 1).



What bridge are you using?

Cheers

-Al

The purpose and the environbent are both different.
Linux designed for speed and performance, this is why using 4K blocks.
Windoze is designed for nothing, this is why can be used for anything a little...

badblock is a powerfull tool to re-allocate the hdd's bad blocks if the quantity is not too many.
Additionally you can detect the weak sectors in more cases, because badblocks writes in the bit matrix (00/55/AA/FF) wich changes allmost all bits in the hdd.
But you are right, caused by the environment, the displayed badblock list can be multiple of the true...



more type.
And you are right, there is differences, but i don't remember for the last, wich have problems...

Janos

I might have missed it, but I still dont get why the number of badblocks listed by badblocks is always far greater than PTD?

For example on a recent disk:

Windows PTD badblock count (4):
1551405
1967364
6358767
71574125

Linux badblocks count (124):
1551360
1551400
1551401
1551402
1551403
1551404
1551405
1551406
1551407
1551408
1551409
1551410
1551411
1551412
1551413
1551414
1551415
1551416
1551417
1551418
1551419
1551420
1551421
1551422
1551423
1551424
1551425
1551426
1551427
1551428
1551429
1551430
1551431
1551432
1551433
1551434
1551435
1551436
1551437
1551438
1551439
1551440
1551441
1551442
1551443
1551444
1551445
1551446
1551447
1551448
1551449
1551450
1551451
1551452
1551453
1551454
1551455
1551456
1551457
1551458
1551459
1551460
1551461
1551462
1551463
1551464
1551465
1551466
1551467
1551468
1551469
1551470
1551471
1551472
1551473
1551474
1551475
1551476
1551477
1551478
1551479
1551480
1551481
1551482
1551483
1551484
1551485
1551486
1551487
1551488
1551489
1551490
1551491
1551492
1551493
1551494
1551495
1967352
1967360
1967361
1967362
1967363
1967364
1967365
1967366
1967367
6358712
6358760
6358761
6358762
6358763
6358764
6358765
6358766
6358767
71574112
71574120
71574121
71574122
71574123
71574124
71574125
71574126
71574127

PTD's numbers are in badblocks sequence, but badblocks count is far higher. Why?

Cheers

-Al

Because PTD uses the Windows's hw driver for test the surface, but badblocks uses the kernel's block layer for access the media.
The block layer is designed for performance use.
It have some readahead settings, cache, and some more.
You have to modify the parameters to get the similar result.
If you modify all, you should have got exactly the 8x result, because the block layer's resolution is 4KB (8 LBA).
If you want to go more deeper, you need to modify the badblocks itself.

In some word:
Badblocks are great, but reports multiple results, wich is not really important, because one HDD is error free, or crap and need to RMA it.

Janos

Ok I get the jist of it.

Sounds like your rule of thumb is one bad block is one too many?

Cheers

-Al

Yes, it is for a drive wich are in warranty period!
The only thing is wich worth a try, a total zerofill and re-test.
(badblocks -vvw)

If the drive passes this, than OK, you can use more.
But if there is any (one of a lot, not important) error, RMA the drive, this is the best, what you can do.

Janos