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

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.

#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.