chkdsk /f or /r

[pcpete]

When we have a bad drive we are trying to make bootable we first make a sector image to a good drive, then run chkdsk /f on the clone. We have never tried chkdsk /r as since we did a recovery of the sectors we did not think it did anything. Is their situations where we would want to us /r?

 

[phaZed]

If chkdsk /f doesn't fix, try /r.. is my general workflow.

I do my cloning with ddrescue.. If going to a same-size drive, chkdsk /f works fine 99.9% of the time.

If I clone a 500GB to a 1TB and want to realize the additional space, it seems only chkdsk /r will "fix" the tables to see the enlarged partition (Using Parted Magic for resizing).

 

[Porthos]

as long as your free space is immediately after the partition

Not always on a UEFI partition. Or when Windows placed a recovery partition at the end of the drive.

 

[phaZed]

Sorry, meant GParted, not "Parted Magic" - brainfart.

I don't ever have luck with system partitions.. windows always gray's out that option. You can't extend the partition if you're running it, either. As @Porthos says, UEFI, extra partitions, etc.

 

[phaZed]

I dunno @Computer Bloke, maybe I'm doing it wrong! Lol. I've simply got a workflow via linux that works for me seeing as I'm mostly using linux for the data anyways.


I grabbed a mildly bad customer drive(some bad sectors) (no worries, already cloned over to SSD!) (Bench machine is Win10 2004) - This an an "offline" operation.

1. Disk3, Drive G: and F: is the one in question (Win10 1903):




2. I can't remove the recovery partitions in Windows, so, let's do that on Linux (Yes, I know I could DISKPART it, but eh.):




3. Move drive over to Linux/GParted, start with this:


.. and end with this:


4. Now, move drive back to Windows to do the grow/resize:



What gives? What am I doing wrong!? Lol.

So, whatever it is I'm doing wrong - this works for me... I just do the end-partitions delete, and the resize in Linux then boot the drive on the customer's machine. The customer machine will do a chkdsk c: /f on first boot usually, but the "Grow" is not realized by Windows, it will say "500GB" instead of the "1TB" I grew it to. After I run a chkdsk c: /r Windows will fix that and it's ready to go with all space realized.

 

[phaZed]

@Computer Bloke That was the customer's physical drive (yes, shame on me lol) so, I don't have another image on hand to test with ATM.

I suppose it could be a GParted issue, though I've found it quite reliable over the years (more of a seat of the pants analysis, I know).

I'll keep MiniTool Partition Wizard in mind and will attempt to remember to carry out that test when the opportunity presents itself.. unfortunately, I don't think MTPW is going to work for me due to their licensing scheme... $700 for their Enterprise offering to only do 299 "devices". I'm not keen enough to save the 3-5 minutes it takes for the chkdsk c: /r.... at least I'm assuming that's how their licensing works... hard to tell if they mean "devices" as in, a single data-recovery machine here at the shop, 1000's of drives... but I'm assuming not based on this blurb from the biz page:


I'd have to buy at least two $700 licenses, maybe more. Ouch!
EDIT: Scratch that, I would be perpetually buying licenses.. so more like $1500+ per year.

 

[phaZed]

Thanks @Computer Bloke - I'll check it out regardless.. I know myself though.. I'm gonna forget, but will try not to haha.

 

[NJW]

I suppose it could be a GParted issue ...

I use gparted for partition management, too. AFAIK, based on my own experience, gparted always marks NTFS partitions as dirty after manipulation, which means Windows will do a filesystem check on the next boot*.

(Equally, it always gives me a moment's panic when Windows boots to a filesystem check ... )

* gparted faqs:

When resizing boot NTFS partitions, it is advisable to perform this as a single operation only. After resizing, boot into Windows twice to allow Windows to perform its checking operations.

 

[SAFCasper]

For the question /r or /f
My answer is actually /b

When you clone a drive sector-by-sector you also clone the areas marked as bad sectors. So the new drive will avoid using those "bad" sectors even though they are perfectly fine now. /b will re-test bad sectors and mark them useable again. It also does everything in /r

As to whether you really need to bother doing /b is questionable. The benefits often aren't worth the added time vs /f especially if the original drive was only slightly failing. Also, if the data is screwed enough that /f can't fix it after recovering to a known good drive.... you probably should be considering a fresh install anyway. All sorts of gremlins could be lurking.

 

[pcpete]

our workflow to resize a failing drive is first to make sector image. Then run chkdsk /f on the new image. Third clone with a program like macrium to do a file system clone which allows you to resize. I think it is better to do a file system clone as I think it creates a cleaner end product as it just copies files to a clean partition as opposed to copying an old repaired file system over to the new ssd. Also macrium does some ssd optimization.

edit added:
also doing a file system clone is faster in some cases if you have a 2tb drive with only 70gb of data

 

[pcpete]

Sorry, meant GParted, not "Parted Magic" - brainfart.

I don't ever have luck with system partitions.. windows always gray's out that option. You can't extend the partition if you're running it, either. As @Porthos says, UEFI, extra partitions, etc.

as to running, just plug the drive into your bench computer to change it

 

[Larry Sabo]

When you clone a drive sector-by-sector you also clone the areas marked as bad sectors. So the new drive will avoid using those "bad" sectors even though they are perfectly fine now.

Huh?. Here's my understanding of what happens.

When you clone the drive, if there is a bad sector, i.e., unreadable sector, the cloning process will either fail or the "bad" sector will be replaced by fill characters. If the sector is replaced with fill characters, the clone will have no "bad" sectors, i.e., sectors that can't be read from the clone, but the programs that expect valid data throughout that sector will not find it, because of the fill characters, and crash, the file will be seen as corrupted, or the data will be invalid.

If the sector was unreadable ("bad") at some point in the past, it will have been reallocated to a spares sector to be used in its stead. Thereafter, data written to the "bad" sector will instead be written to the spares sector and the cloning process will read the spares sector. The data content of the clone will be whole, as if no problem existed with the drive, as far as the reallocated sector is concerned.

If a sector is marked by the drive as pending reallocation and is not readable during cloning, it's a read failure and the cloning program will fail or the clone will contain fill characters instead of what originally was in the unreadable sector. If the pending reallocation sector is readable during the clone process, the pending flag is reset to indicate that the sector is actually good and the data output will be whole.

 

[SAFCasper]

Huh?. Here's my understanding of what happens.

When you clone the drive, if there is a bad sector, i.e., unreadable sector, the cloning process will either fail or the "bad" sector will be replaced by fill characters. If the sector is replaced with fill characters, the clone will have no "bad" sectors, i.e., sectors that can't be read from the clone, but the programs that expect valid data throughout that sector will not find it, because of the fill characters, and crash, the file will be seen as corrupted, or the data will be invalid.

If the sector was unreadable ("bad") at some point in the past, it will have been reallocated to a spares sector to be used in its stead. Thereafter, data written to the "bad" sector will instead be written to the spares sector and the cloning process will read the spares sector. The data content of the clone will be whole, as if no problem existed with the drive, as far as the reallocated sector is concerned.

If a sector is marked by the drive as pending reallocation and is not readable during cloning, it's a read failure and the cloning program will fail or the clone will contain fill characters instead of what originally was in the unreadable sector. If the pending reallocation sector is readable during the clone process, the pending flag is reset to indicate that the sector is actually good and the data output will be whole.

Well, it's not actually cloning the bad sectors data that I'm referring to. Just the map that says sectors X, Y and Z are bad.

- Old drive has bad sector at number 1228
- Filesystem detects this and marks sector 1228 as bad. Don't try using it again.
- You clone to a new drive using a full sector process like ddrescue
- The filesystem still thinks sectors 1228 is bad so won't use it.

That's why I say it's questionable whether /b is necessary. It's not really a concern about corrupted data. But technically you are loosing sectors of the new drive for no good reason.

I like @pcpete approach of making a sector image. Repair that with Chkdsk /f. Then use a Macrium files only "smart" clone. Sounds like you are getting the best of both worlds and none of the negatives (besides maybe taking longer).

Or you know... just backup the data and fresh install. Always the preferred option when possible.

 

[Larry Sabo]

The file system doesn't manage bad sectors, the hard drive firmware does. This explanation of bad sector processing is helpful. For a more-in-depth discussion, DeepSpar has a white paper that also explains the strategy used by their disk imager.

 

[Larry Sabo]

I have to admit that I'm pretty ignorant of how Window identifies and manages bad blocks (I think you meant blocks). The third paragraph of this DeepSpar article is the best I've seen about what happens when Windows can't read a block of data from the drive. I don't think Windows actually reads individual sectors but I'm probably wrong.

 

[Porthos]

Or you know... just backup the data and fresh install. Always the preferred option when possible.

Yep.