34

I'm running badblocks (or rather "e2fsck -c") on a 1TB drive and if the progress indicator is any indication (no pun intended), it's going to take almost forever to complete.

Right now it says 0.01% done, 30:20 elapsed which would mean the thing would take 17 weeks or so to complete, which seems rather excessive in my book.

Is that a normal amount of time for such a check to take or it simply that my suspicions are correct in that the drive is failing, thus causing the check to take only slightly shorter than eternity?

I found this question here, but that pertains to the amount of passes done.

  • 3
    It almost certainly depends on the interface, the drive, and how bad the drive is, if there is actually any failures. I can tell you on one of my computers a badblocks scan took ~70 hours for a 1.5TB drive attached through SATA. If you where connected via USB2.0, or 1.0 it would be far longer. – Zoredache Feb 2 '11 at 0:38
  • It is attached using e-SATA. I suppose I'll just give it a while and see how far along it is after a good night's sleep. – Steven Don Feb 2 '11 at 0:43
  • @Zoredache - I think your comment should be an answer instead. – Nifle Feb 2 '11 at 6:02
  • In addition to Zoredache's comment above, different switches to badblocks cause it to perform different tasks, which will also affect runtimes, for example the -w switch. – JeffG Mar 7 '11 at 17:58
  • 1
    The time required would (also) depend on the mode badblocks is running in: read-only, non-destructive read-write or destructive read-write. Having said that, 30 minutes for 0.1% does seem long. – SabreWolfy Jun 22 '12 at 14:10
24

To answer you question, the closest I can offer is with a 3TB I tested for this. Here are the 3 times tests I did, only changing the parameter values for -c and only doing them up to 10% since they took A LOT of time. Each was done 3 times to get an average.

badblocks -svn /dev/sdb

To get to 1%: 1 Hour
To get to 10%: 8 hours 40 minutes

badblocks -svn -b 512 -c 32768 /dev/sda

To get to 1%: 35 Minutes
To get to 10%: 4 hours 10 minutes

badblocks -svn -b 512 -c 65536 /dev/sda

To get to 1%: 16 Minutes
To get to 10%: 2 hours 35 minutes

So yes, the -c parameter has a very big influence on the time it takes to check the drive. I would guess that for a 1 TB Hard drive, assuming it maintains the same time frame as the 3TB, it would be 1/3 of the time mentioned here, so to get to 10% with -c 65536 on the 1 TB HDD it would be about 50 minutes.

| improve this answer | |
  • There seems to be a big difference in the type of check as well. With read-only on a 5TB external USB harddrive, I get to 10 % in about an hour, which is about four times faster then the fastest response above. I am using default value for -c and -b 4096 (the default 1024 would not even start the test, apparently, 5 TB is too big). – sup Mar 22 at 12:39
  • Thank you and yes, there is a time difference depending if its an HDD (and the RPMs for it), an SSD (and what sata type it is), an nvme (and the pci express it is based on), if its a USB 2, 3.X and more. Since this was tested 6 years ago I can guess it will take less right now for example on a 1TB samsung ssd or a monster nvme (one of those with 3.5gb speeds) – Luis Alvarado Mar 23 at 1:27
  • 1
    Yes. It is still the top of google results, that is why I updated it. My disk is 5400 RMP USB3, so for sure it might also make a difference. – sup Mar 24 at 9:41
5

Badblocks makes 4 runs. On a 1 TB external HD it usually takes around 70 hours.

| improve this answer | |
  • 4
    For completeness, badblocks (only) defaults to four runs with the -w destructive-write flag. – SabreWolfy Jun 22 '12 at 14:09
  • @SabreWolfy where did you read that badblocks does for runs with -w? I cannot find this information. – Alan Franzoni Mar 31 '17 at 9:30
  • 1
    The man page for -w shows the four write patterns it uses. – SabreWolfy Mar 31 '17 at 9:35
4

Try increasing amount of blocks processed together, like in badblocks -svn -b 512 -c 65536 /dev/sda. In this way, I can get a 1 TB hard disk drive checked in 8 hours.

| improve this answer | |
3

I'm running badblocks on WD Red 4TB drives. Since they're 4k sector drives (checked using lsblk -o NAME,PHY-SeC) I'm running it with -b 4096. I wanted to give each of the badblocks instances ~800Mb of RAM so I used -c 200000 which gives you 4096 bytes * 200,000 blocks = 800,000 Kb. They started out with abour 800Mb each but that crept up over time. These settings do provide a significant speedup over standard settings though.

It ran 1% in 3min 56sec but that's 1% of 4 patterns. It also seems to take more time the closer you get to the end of a run. It checked the disk with the first pattern in about 17hrs so it should complete 4TB in about 68hr.

COMMAND BELOW RUNS A DESTRUCTIVE WRITE

Command I'm using is: badblocks -svw -b 4096 -c 200000 /dev/sdc -o bb_sdc.txt

| improve this answer | |
0

Ran this the day before yesterday on a failed 1 TB drive in my 6TB RAID 6 (DESTRUCTIVE WRITE MODE!):

# badblocks -svw -b 4096 -c 65536 /dev/sdb

Mainboard is an ASRock Rack C2550D4I (I know…) with 8x Samsung SpinPoint M8 HN-M101MBB (I know…) connected to the SATA3 Ports. The drives are 4K "Advanced Format" drives, hence the 4K block size.

badblocks took about 28 hours to finish, with no errors.

The single drives do ~105 MB/sec (average hdparm -tT buffered read timing), 200–230 MB/sec when testing the whole array. Nothing superior, nowadays, but nice for a pile of old Laptop drives.

Hope this helps as much as this thread helped me to find a quick way to do a badblocks run on the disk. I know its use is dubious these days, but when a previous smartctl -t long failed due to read failures, I decided to have all sectors touched and rewritten a few times to see how the S.M.A.R.T. values would change. Another smartctl Test is pending, if that again fails, I shall shop for a new drive.

| improve this answer | |
0

Some performance observations:

I'm running e2fsck -c -c -v /dev/sda2, which resides on this device:

/dev/sda2  77056 976754431 976677376  3.7T Linux filesystem

The current runtime for 63.5% is 53:28:40; 53.5 hours. The rate of progress is 1.186%/hour. At this rate, it will take an additional 31 hours to complete, with an estimated total run time of 85 hours. This a USB 3.0 device. iotop indicates the average read/write speed is about 25MB/s. So far, zero bad blocks have been found.

The underlying command line run by e2fsck is:

sh -c badblocks -b 4096 -X -s -n /dev/sda2 976677375

Posts to StackOverflow state it is safe to interrupt badblocks with ^C (SIGTERM). Should I do so, I don't see the downside of stopping this test, and resuming it in the future later, as this is a disk block-level operation. I must unmount this filesystem before resuming at the percent scan completed.

| improve this answer | |
  • 3
    is this a question or answer? – Pierre.Vriens May 27 '18 at 11:51
0

I know this is an ancient question but, to bring it up to date, I'm currently testing a 14TB drive using:

sudo badblocks -wsv -b 4096 -c 262144 -p 4  /dev/sda | tee badblocks.log

and am getting around about 24.7 hours per single read or write of the entire surface.

This gives an average speed of 165 MiB/s, which is about the same ballpark number as I get from fio when using large blocksiz to sequential write the entire surface. Driving machine is a rasperry pi 4 over usb3, so maybe there are some gains to be had using a SATA connection?

Remember that badblocks writes the entire surface with a pattern, then goes back and reads it. It does this with 4 different patterns, so a single "pass" does 8 R/Ws of the surface. In my case, I've asked it to do all that 4 times (-p 4), so I'm expecting this test to take about 33 days...

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.