Finally got Chkdsk error

[rsutoratosu]

Server 2008 - finally got this error.

The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume \Device\HarddiskVolume2.

-I used to run chkdsk when encounter this, read a few article about how evil chkdsk is

What should I use instead of chkdsk?

 

[Ketchup]

I am not sure what is so evil about chkdsk. It is just Windows telling you that there is an error with the file structure on that drive/partition. I would let it do the repair. If more crop up, it may be time to replace the drive.

 

[KingFatty]

I don't think the 'evil' stigma is attached to chkdsk specifically.

Instead, the 'evil' stigma is attached to doing any kind of anything to the disk after receiving the error.

So, let's say you are writing a novel and have invested 10,000 hours of your life into it. So it's worth like hundreds of thousands of dollars to you. And, since you are a writer, you aren't aware of the benefits of backing up. So, you one single copy of the book is on this one hard drive and it gets this error on the hard drive.

So do you then turn around and start screwing with the disk? Well, it's such valuable irreplaceable data on that disk, that instead you pay $1000 for data recovery professional services to perform the safest, most careful fix of the data so that they preserve all the data and don't further corrupt it.

If you just run chkdsk, the file system will be repaired, but perhaps you'd risk losing a couple pages of data that are corrupted, but maybe could have been salvaged by professionals.

However, if you are a computer enthusiast, I think you'd appreciate the benefit of backing up data. Therefore, you don't give a crap about losing some pages of your book, because it's already backed up in triplicate elsewhere. So you run chkdsk, fix the inconsistencies in the file system (which may be nothing, or may be caused by physical damage on the disk where some blocks will be marked bad), and then verify all your data using the backup software to ensure nothing is messed up, or find messed up differences and overwrite them, or just nuke the drive and restore it completely from a safe backup.

Chkdsk is not the problem. Using unsafe computer practices is the problem.

 

[imagoon]

The "evil" is the fact that chkdsk repairs the file system by deleting the corrupted information and rebuilding it. This can result in the files stored in the corrupted area being partly lost. Thing is, this data was likely "lost" anyway and only a professional sector level repair would have a real chance at recovering it. I am sure after that $1000+ bill you would invest in an external HDD to backup to / dropbox / crashplan / whatever.

Basically like KingFatty said.

 

[rsutoratosu]

nevermind, someone rebooted the server after installing some stuff, i didn't even get to play with it.. 🙁

but is there something else that does a better job than chkdsk or at least in reporting, back in the days you got those nice norton utilities 🙂

 

[Cerb]

nevermind, someone rebooted the server after installing some stuff, i didn't even get to play with it.. 🙁

but is there something else that does a better job than chkdsk or at least in reporting, back in the days you got those nice norton utilities 🙂

Reporting...what? For NTFS Filesystem problems, Windows' NTFS driver and Chkdsk are it. For disk/cable errors, there's the event logs. For preventative checking, since some values can mean impending doom, but don't always mean that, any number of utilities can be used to check SMART data.

If there have been no errors, and it shut down and rebooted correctly, there's nothing to check, except for your backups 🙂. With everyone using fluid bearings, now, drives go from mildly bad to, "he's dead, Jim," really fast, without enough warning to do anything about it (it used to be common that mechanical failures would be preceded by bearing noise). Oh, sometimes you get enough warning, but it's more common not to; or the "warning" to be buried in logs somewhere, and the failure occur in between the intervals you check them. IE, you can go from 0 uncorrectable reads and no remapped sectors to having hundreds or thousands of them, and an irreparably hosed file system (assuming no RAID), in well under a day, assuming the failure isn't a near-immediate catastrophic one.

You don't need better utilities, going forward, but to change your mindset. The failures themselves tend to be rare enough, but are unpredictable enough that you can't trust any kind of health monitor, only whatever processes you have to recover from the failures.

 

[rsutoratosu]

chkdsk reporting sucks, thats the only thing i dont like about it, they dont always tell you what file is wrong and when there are long errors, it fills the history buffer, unless you increase that before you run it but you can't since it runs on reboot most of the time

 

[Cerb]

chkdsk reporting sucks, thats the only thing i dont like about it, they dont always tell you what file is wrong and when there are long errors, it fills the history buffer, unless you increase that before you run it but you can't since it runs on reboot most of the time

http://en.wikipedia.org/wiki/Complex_question

You're asking about better tools, making assumptions about what the one you're erroneously using is there for, and can do. The file system is not a robust database format. Why? Because there are enough common failures that that wouldn't help with, and the preventative measures for them also work against those that would be aided by making the FS more resilient. People generally value speed, instead.

For example, you assume that Chkdsk can discern what file it's dealing with. Sometimes it does, and usually tells you. But, see, there's a bit of a catch-22: if the information that is necessary for it to know that is there, then it won't report an error about an unknown chunk at some index. That data is already corrupt/gone, at that point. It can't tell you what it doesn't know, and to get much more than it knows will take an experienced data recovery professional, who's good at making the right speculations. Speculation is something chkdsk will never do, by design, and that's a good thing.

By the time you've reached a point where you even care about chkdsk's log, beyond making sure it didn't actually have to fix anything, you need your backups. Not understanding this can and will cause someone else's data to be lost. The problem is not chkdsk: it's whatever caused chkdsk to need to be run in the fist place.

 

[mikeymikec]

I encounter dodgy disks through my work in one of three ways (off the top of my head):

1 - Customer says that their computer is acting weirdly in some weird yet easily definable way, let's say IE keeps crashing. As I investigate the problem, I notice loads of disk errors pointing to the main disk in the event log.

2 - Customer says that their computer fails to boot Windows sometimes or freezes up left right and centre after booting.

3 - 'Primary hard disk 0 not found' or computer hangs at BIOS screen.

Scenario 1 could possibly be the start of a dodgy disk that is going to fail soon, but you've got time to do a backup before trying anything remedial, however you would probably get away with a full chkdsk unless you're unlucky. Do a backup first, why risk it? A full drive check stresses out a drive. Once you've got a backup, do the full check.

Scenario 2 & 3 - Do not boot Windows any more, seriously. Attempt a backup before anything else. Using data recovery software if necessary (or even possible) might be an idea, or a not-full chkdsk (being /f, a full chkdsk is /r, I personally do /f /v /r for a full one because MS's documentation isn't consistent on whether /v is FAT32 only, at worst /f and /v are ignored and a full chkdsk is run anyway), depending on a judgement of the circumstances.