Badblocks command taking too long. How can I safely stop it?

Status
Not open for further replies.
A

amarshonarbangla

Weaksauce
Joined
Jan 4, 2013
Messages
86
I started running badblocks (Parted Magic) on a 3TB drive a couple of days ago in non-destructive read/write mode. At the rate it's going, it will take a week to finish! Maybe because the drive is full. How can I stop the command without affecting the data that's on it?
 
How did you start it?

Ordinarily you would just kill the job. If you have it open in a console, usually just CTRL-C. If you don't have the job on a terminal, you need to open a terminal, find the job number, and kill it.
 
Last edited:
I just used the command badblocks -nvs /dev/sdc

I am using it from a Parted Magic disc.

I ran it non destructive mode. Is that an issue?
 
JoeComp said:
It is not a very useful test to run it without writing.

But if you ran it in read-only mode, what are you worried about? Stop the job or shut down the computer, it will make no difference to the drive.
Click to expand...

-nvs is a write-test, the difference is it reads a sector, puts it aside, writes its pattern, verifies the pattern, then writes the original data back to it and moves on to the next. certainly a lot more steps than just letting it not have to worry what data is there and just destructively write-read.
 
Have you tried CTRL-C to stop the badblocks job?
 
Last edited:
JoeComp said:
Incorrect. From the man page:

Code: 
       -n     Use non-destructive read-write mode.  By  default  only  a  non-
              destructive  read-only  test  is  done.  This option must not be
              combined with the -w option, as they are mutually exclusive.

You are getting confused because they talk about the "read-write mode". That is a terrible way to refer to it, but I can state with assurance that no writing whatsoever is done with the -n flag, not even the silly process you describe above.
Click to expand...

I am not an expert on this, but why would it take so long if it was a read only test? I would assume -nvs is doing what DPI described, thus taking a ludicrous amount of time, although the description on the main badblocks page seems to negate that. There's no bottleneck anywhere in my system, I can assure you.
 
DPI said:
-nvs is a write-test, the difference is it reads a sector, puts it aside, writes its pattern, verifies the pattern, then writes the original data back to it and moves on to the next. certainly a lot more steps than just letting it not have to worry what data is there and just destructively write-read.
Click to expand...
JoeComp said:
Incorrect. From the man page:

Code: 
       -n     Use non-destructive read-write mode.  By  default  only  a  non-
              destructive  read-only  test  is  done.  This option must not be
              combined with the -w option, as they are mutually exclusive.

You are getting confused because they talk about the "read-write mode". That is a terrible way to refer to it, but I can state with assurance that no writing whatsoever is done with the -n flag, not even the silly process you describe above.
Click to expand...

No! You (JoeComp) are wrong!

DPI is precisely correct with his/her description of the -n operation.

Trying to argue further will only embarrass you more.
 
amarshonarbangla said:
I am not an expert on this, but why would it take so long if it was a read only test? I would assume -nvs is doing what DPI described, thus taking a ludicrous amount of time, although the description on the main badblocks page seems to negate that. There's no bottleneck anywhere in my system, I can assure you.
Click to expand...
The (non-destructive) -n operation "should" take twice as long as the (destructive) -w operation. Consider: -n must do read (original)-write (pattern)-read/verify (pattern)-[re-]write (original); but -w only needs to do write (pattern)-read/verify (pattern). But, that, alone, does not explain the ludicrous duration you are seeing.

Your -n run is taking so long because you are using the default block-size (1024) and default block-count (64). Those defaults are not so bad with any of the other badblocks operations, because all writing (of the entire run [default entire device]) is completed, then all reading (verifying) is done; thus, the disk is able to stream effectively.

With the -n, the r-w-r-w steps are performed explicitly (in default 64KB "chunks"), causing the disk to constantly "lose" revolutiions. If you add -b 32768 and -c 2048 to your badblocks options, you will do 64MB chunks and essentially optimize the -n performance/duration.
 
Last edited:
JoeComp said:
Incorrect. From the man page:

Code: 
       -n     Use non-destructive read-write mode.  By  default  only  a  non-
              destructive  read-only  test  is  done.  This option must not be
              combined with the -w option, as they are mutually exclusive.

You are getting confused because they talk about the "read-write mode". That is a terrible way to refer to it, but I can state with assurance that no writing whatsoever is done with the -n flag, not even the silly process you describe above.
Click to expand...

They specifically state the default is a non-destructive read-only test, while -n is a non-destructive read-write test. If -n is also a read-only test then what purpose does it serve?
 
I did a test with vbox and it's plainly obvious it does a non-destructive write:
Code: 
badblocks -nsv /dev/sdb
Checking for bad blocks in non-destructive read-write mode
From block 0 to 10240
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                
Pass completed, 0 bad blocks found.

For comparison's sake, here's what it looks like without the -n flag:
badblocks -sv /dev/sdb
Checking blocks 0 to 10240
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.
Click to expand...

I'm only posting because I took the damn time to verify it, even if he edited out his "I can state with assurance that no writing whatsoever is done with the -n flag" statement. WTF, stating with assurance and putting down others that are correct? :confused:

Seriously, that kind of attitude can cause real issues for folks that are genuinely asking for help if it were something more critical.

UhClem said:
So, you really didn't test it at all! But thought you'd be able to "brashly bluff" me/us. Well, the only credit you get is for realizing that you were not going to get away with it, and modifying your stance.
Click to expand...

I was quite baffled because it's really quite clear what the man page says. I wonder if he forgot to add the -n flag and saw the default prompts and thought he was right?
 
Last edited:
Neb said:
Seriously, that kind of attitude can cause real issues for folks that are genuinely asking for help if it were something more critical.
Click to expand...

So, do you claim that CTRL-C is not the way to stop the badblocks job? That is the question that the OP asked. Did I give him poor advice to use CTRL-C? Do you have a better solution?
 
JoeComp said:
So, do you claim that CTRL-C is not the way to stop the badblocks job? That is the question that the OP asked. Did I give him poor advice to use CTRL-C? Do you have a better solution?
Click to expand...

I was about to type out that a cancellation via ctrl-c is correct, but my goodness...you love to be right don't you? OP also asked why a read-only test would take so long, a question that was brought up when you mentioned that -n was a "read-only mode". That was brought up by YOU. Did you give him incorrect information, which I took the time to test and respond to? Yes. Did you correct your bad information and let the OP know that? No, you just deleted it all and are pretending it never happened.

amarshonarbangla said:
I am not an expert on this, but why would it take so long if it was a read only test? I would assume -nvs is doing what DPI described, thus taking a ludicrous amount of time, although the description on the main badblocks page seems to negate that. There's no bottleneck anywhere in my system, I can assure you.
Click to expand...

There's no bottleneck, it's just a fairly time intensive process to move data out of the way and back. -nvs is indeed doing what DPI described and the man page actually agrees with DPI, though the mention of the default mode can be a bit misleading. They're just trying to mention how the default behavior is in comparison to the -n behavior.
 
Last edited:
Neb said:
I was quite baffled because it's really quite clear what the man page says. I wonder if he forgot to add the -n flag and saw the default prompts and thought he was right?
Click to expand...

It is not so clear if you know that many linux commands have an explicit option for the default behavior. I had thought that it meant that the -n mode was the default behavior, so I tested it without the -n. But you are correct that there are actually three modes, read-only, destructive write, and the -n mode.
 
Neb said:
Perhaps. I'm just annoyed I took the time to setup a vbox VM to test it only to see all your posts edited out.
Click to expand...

So first you criticize me for posting something incorrect, and now you say you are annoyed because I corrected it? :confused: Sounds like you are just looking for reasons to criticize me.

I notice your posts #18 and #20 were edited as well.

I also note that you did not answer the OP's original question, and only even mentioned it when I prompted you about it.
 
I am glad other people replied to this thread, correcting misinformation. I did use Ctrl-C to cancel the job. It said something like "Job interrupted. Cleaning up", then nothing happened. I left it there for 10 mins but the cleaning up message never went away. I ended up restarting my computer. All the data seems to be intact.

UhClem said:
The (non-destructive) -n operation "should" take twice as long as the (destructive) -w operation. Consider: -n must do read (original)-write (pattern)-read/verify (pattern)-[re-]write (original); but -w only needs to do write (pattern)-read/verify (pattern). But, that, alone, does not explain the ludicrous duration you are seeing.

Your -n run is taking so long because you are using the default block-size (1024) and default block-count (64). Those defaults are not so bad with any of the other badblocks operations, because all writing (of the entire run [default entire device]) is completed, then all reading (verifying) is done; thus, the disk is able to stream effectively.

With the -n, the r-w-r-w steps are performed explicitly (in default 64KB "chunks"), causing the disk to constantly "lose" revolutiions. If you add -b 32768 and -c 2048 to your badblocks options, you will do 64MB chunks and essentially optimize the -n performance/duration.
Click to expand...

I am not clear on this. What's the difference between running 64MB chunks rather than 64KB chunks? Wouldn't running smaller chunks "stress" the drive more, resulting in a better "stress" test?
 
JoeComp said:
So first you criticize me for posting something incorrect, and now you say you are annoyed because I corrected it? :confused: Sounds like you are just looking for reasons to criticize me.

I notice your posts #18 and #20 were edited as well.

I also note that you did not answer the OP's original question, and only even mentioned it when I prompted you about it.
Click to expand...

I only criticized you because you deleted all context rather than correcting it. Yeah, I added a few lines to post 20, but didn't delete or change the context of my post. Didn't answer the OP's question because it seemed that they had already gotten that, but they had questions about the latest topic which was the read-only part. That being said we're both veering offtopic, so I'll stop here.
 
Neb said:
I only criticized you because you deleted all context rather than correcting it.
Click to expand...

I did correct it. Unless I am mistaken, I edited all of my posts that had incorrect information, removing the incorrect information so as not to cause further confusion.

So, it seems you do not like me posting incorrect information, and you do not like me correcting posts that had incorrect information. And you do not like me to post correct information because you say I "love to be right". Is there anything that I can possibly do that you will not criticize me for? :confused:
 
amarshonarbangla said:
I am glad other people replied to this thread, correcting misinformation. I did use Ctrl-C to cancel the job. It said something like "Job interrupted. Cleaning up", then nothing happened.
Click to expand...

The job was already cancelled the instant you hit CTRL-C. There was no need to wait at all.
 
amarshonarbangla said:
I am not clear on this. What's the difference between running 64MB chunks rather than 64KB chunks? Wouldn't running smaller chunks "stress" the drive more, resulting in a better "stress" test?
Click to expand...

The reading and writing to every sector is enough of a stress test IMO, doing it in an efficient manner is more important to me than tossing even more reads/writes. I'm curious though, why are you stress testing a drive that has data on it? Stress testing a drive does occasionally make it fail, do you have that data backed up?
 
JoeComp said:
I did correct it. Unless I am mistaken, I edited all of my posts that had incorrect information, removing the incorrect information so as not to cause further confusion.

So, it seems you do not like me posting incorrect information, and you do not like me correcting posts that had incorrect information. And you do not like me to post correct information because you say I "love to be right". Is there anything that I can possibly do that you will not criticize me for? :confused:
Click to expand...

Corrections vs deletions. Correcting provides context whereas wholesale deletion oftentimes causes confusion by people visiting the thread at a later time.
 
Neb said:
Corrections vs deletions. Correcting provides context whereas wholesale deletion oftentimes causes confusion by people visiting the thread at a later time.
Click to expand...

Deleting incorrect information is correcting. Now you are saying that you wanted me to leave incorrect information in my posts in order to not cause confusion?

Could it be that what you really want is for the incorrect information to remain, not because you really think it will cause less confusion to have incorrect information, but because you really want to criticize me?
 
JoeComp said:
Have you tested it? Calling it a "read-only test" in the man page is extremely poor documentation if it is actually writing to the drive.
Click to expand...
==>> Isn't this interesting?? <<==

Your initial version of this reply to my posting (prior to your 1:10pm edit) stated:
I just tested it (again!). There is no writing done by the -n option. Just as it's stated in "only a non-destructive read-only test is done" from the -n man page description.
Click to expand...
So, you really didn't test it at all! Did you?

[Now, you have "edited" that posting again, and it is no longer even a reply to my posting.]
 
UhClem said:
So, you really didn't test it at all! Did you?
Click to expand...

I did test it, as I already explained, I made the mistake of assuming -n was the default option.

It seems you made the mistake of not reading my post where I explained that.
 
JoeComp said:
So, do you claim that CTRL-C is not the way to stop the badblocks job? That is the question that the OP asked. Did I give him poor advice to use CTRL-C?
Click to expand...
Who knows what "advice" you actually gave? There is so much evidence of you making massive revisions of your postings.
 
UhClem said:
Who knows what "advice" you actually gave? There is so much evidence of you making massive revisions of your postings.
Click to expand...

Why are you repeatedly trying to harrass me about a mistake I made and corrected?

And I'm sure the OP knows what advice I gave, since he followed it (CTRL-C to stop the job).
 
JoeComp said:
I did test it, as I already explained, I made the mistake of assuming -n was the default option.

It seems you made the mistake of not reading my post where I explained that.
Click to expand...
Your "explanation" was a post-facto revisionist cover-up of your mistake. Maybe you should apologize to all the posters you labeled as wrong and incorrect, rather than just editing your posts, after the fact, in an attempt to escape the accountability.
 
I posted some incorrect information, then I corrected it and explained how I made the mistake. Unless you never make mistakes, you can stop harrassing me now and stop diverting this thread off-topic.
 
JoeComp said:
The job was already cancelled the instant you hit CTRL-C. There was no need to wait at all.
Click to expand...
In the general case, your statement would be correct. But, in the case of badblocks, and many other utilities that have a responsibility to restore a clean state of affairs, it is quite wrong. You need to read up on the Unix signal mechanism.
 
The point of this thread has been lost by the bickering back and forth. Names have been recorded, so don't make it a habit.
 
Status
Not open for further replies.
Back
Top