Microsoft Redesigns chkdsk For Windows 8, Improves NTFS Health Model

MojoKid writes "Microsoft can't do anything to magically make hard drives stop failing when parts go bad, but Redmond is rolling out a new NTFS health model for Windows 8 with a redesigned chkdsk tool for disk corruption detection and fixing. In past versions of the chkdsk and NTFS health model, the file system volume was either deemed healthy or not healthy. In Windows 8, Microsoft is changing things up. Rather than hours of downtime, Windows 8 splits the process into phases that include 'Detect Corruption,' 'Online Self-Healing,' 'Online Verification,' 'Online Identification & Logging,' and 'Precise & Rapid Correction.'"

Comments

v8 chkdsk on windows 7?

[schwit1]

chkdsk is a standalone app. Can I use v8 on my v7 OS?

Re:v8 chkdsk on windows 7?

[Anonymous Coward]

Part of what the team has been doing since Windows 7 is to refactor large monolithic DLLs (like kernel32 and advapi) into smaller DLLs that are layered more properly and quicker to load (due to reduced size). Windows 8 continues this work. This is part of the whole "minwin" effort that lots of people in the (external to MS) rumor mill got excited about a few years back. (At least minwin is what they used to call it. Core system is another term used later.)

As a result of this work, in Win7 and Win8, most binaries you find in system32 depend on newfangled DLLs not present in a downlevel system and will thus not load on an older version of the OS. So I doubt it. (Not to mention that this new thing in particular, since it's about modifying online filesystems, might depend on new ioctls or other hooks in ntfs.sys or maybe some other driver - though I can't say I know that for sure.)

-Former Windows dev.

Re:Improves chkdsk? Heh.

[sco08y]

Considering that the current chkdsk is actually capable of causing massive logical damage , Microsoft has a LONG way to go to make it function as intended.

You mean it's suspected of causing additional damage in a couple of comments.

It's very possible that there are long standing bugs. It's also possible that it just tried very hard on a hopelessly borked drive and failed.

Re:No more hours of downtime

[Mashiki]

If anyone wants an example of why RAID should always have a backup solution and not just and/or solution. Please check http://dslreports.com/ , as they just recovered from a powerloss at nac.net which took their entire array system with it, and fudged 2 years worth of data, which had to be sent off for recovery. That was on April16th, the site is just starting to come back up in the last two days.

Some info here: https://docs.google.com/document/d/1kll86bDn_MgWoo6Ja7oHo_yvI0SCqggEvNWwPWIcrHY/edit?pli=1

Re:No more hours of downtime

[LordLimecat]

Because there is basically no point to it. The point of indexing is that rotational media has substantial access time penalties for fetching various info from random locations on the drive. By indexing it, you place all that metadata in one place so you can get a sequential read.

But with an SSD, there is not a substantial difference between random and sequential reads, and no significant penalty, so the indexing is not terribly useful. Additionally, indexing means more writes as well as increased background reads, which not only impacts performance (for little gain) but also wears out the drive.

Ditto for defragmenting; in fact defragging and indexing attack the same core problem, but from different angles, which is why neither is necessary on an SSD.

#1 thing I want - block-level checksums

[PhunkySchtuff]

The number 1 feature I want in current filesystems is block-level checksums.
I've had to perform data recovery for a number of people recently (yes, backups help, but sometimes having them just 24 hours out of date means there are advantages to attempting to recover the data off the failed or failing drive or array)

Now, using a combination of tools I've been able to get the faulty drive to give me back data, but I've got no way whatsoever of knowing if the data it's given back to me is actually the data that was stored on it in the first place.

Having end-to-end checksums would easily allow me to assign a confidence level to data recovery procedures, letting me know that the data I have retrieved is what was stored - it would also allow better control over operations like fsck or chkdsk if the blocks that hold metadata are also checksummed, that way it would be possible to tell if a block has been randomly corrupted somehow, or if it's stored as intended.