How to identify a corrupted file system early

disk-utilityfilesystem

I recently had an external hard drive develop a corrupted file system. At first, I started noticing some errors when trying to open certain files on it, and now OSX has told me that it has frozen the disk as read-only. I have everything backed up, so it is not a catastrophic problem. But, it is still a hassle to deal with. I would like to find a way to identify such issues sooner.

I'm not concerned about identifying bad sectors or failing hardware issues (such as discussed here: How to identify and fix files with corrupted / inaccessible disk blocks), as I have other software in place already to deal with those.

My naive approach to this would be to either:

(a) write a script that goes and tries to open all of my key files periodically to check for errors and/or (b) periodically doing full checksums against my backup. Both of these, however, seem both slow and troublesome in terms of the extra wear they put on disks.

My ideal solution would:

Identify file system corruption early
Pinpoint precisely which files/directories are affected (so that I can address just those affected locations).

If that second point isn't really achievable (I'd need to have a pretty high confidence in getting every problem file and location identified), then I'd at least settle for the first.

I know that there is some third party software (e.g. Diskwarrior) that advertises an ability to diagnose these problems early, but I am unclear about how effective it actually is at that.

Best Answer

This is what SMART status is for.

I use a product called DiskDrill, that besides the recovery tools (paid) they have a number of free utilities including a SMART status monitor that will warn you proactively if a number of erros start popping up.

As for you data, the best approach is the "ounce of prevention is worth a pound of cure" approach. Create and stick to a back up plan where you have not one (Time Machine) backup, but a secondary (like iCloud and OneDrive). When you have multiple copies, you greatly reduce the chance of data loss.

Related Solutions

MacOS – How to identify and fix files with corrupted / inaccessible disk blocks

If you are facing a healthy file system at the level of its structure and want to find files which have disk faulty blocks, here is how I would proceed:

Make a full backup of your disk with Time Machine or Carbon Copy Cloner

Check this backup.
Run the following heavy and risky (in case you do have bad blocks outside of your filesystem structure) command (make sure the {} is quoted so filenames containing spaces work):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

This heavy find command will print for any plain file its name (thus not reading it, but just its directory entry) and then continue making a full and fast read of all its data blocks.

Upon hiting the first file containing bad blocks, this find will cause the kernel to log read error on /var/log/system.log, and it will either slow down or bring your system to a total halt. This will mostly depend on the hard drive capacity to relocate the bad blocks found on its internal pool dedicated to this usual fix task. This file containing bad blocks will be the last name printed by find.

Write down this file name on a piece of paper! Let's say that this file name is:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

At this point you may have the possibility to kill find quickly by hiting ctrl+C. If killing it nicely is failing, just crash your Mac.

Upon rebooting your Mac, directly check the file containing bad blocks:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

If the command terminate correctly, then the error was light enough for your disk to be able to read this file and reallocate the bad blocks.

If the command doesn't terminate, you won't be able to kill it normally, your data is totally lost, and you will have to crash your Mac once more.

In this last case, you have to consider replacing your disk and to work from your last backups. Some other files might also contain bad blocks and may have stayed undetected since a long time as long as you didn't read them.

The kernel won't fire a read error on a block you never read.

MacOS – External disk – Unrecognized file system (-69846)

Try this in the exact order:

#FOR THE WHOLE DISK
diskutil eject /dev/disk2               #Eject the disk 
diskutil mountDisk /dev/disk2           #Re-mount the disk

#FOR THE VOLUME(S) OF THE DISK
diskutil list                           #list volume identifiers. 
diskutil mount /dev/disk2sXXX           #Mount the Volume. Dont enter a disk ID
diskutil repairVolume /dev/disk2sXXX    #Repair the Volume. Dont enter a disk ID

Basically you are trying to correct previous mounting/ejection related errors by making sure the disk is safely ejected before you do anything else.

Once that is out of the way, have the disk re-mounted. Next, have the volume re-mounted. Finally, repair the newly mounted volume.

Additionally, double check for any human error. Did you want to repair the volume or the disk because you specified a disk identifier to repair a volume. You typed:

diskutil repairVolume /dev/disk2

it should be

diskutil repairVolume /dev/disk2sXXX

Or use repairDisk if you wanted to repair a disk.

Best Answer

Related Solutions

MacOS – How to identify and fix files with corrupted / inaccessible disk blocks

MacOS – External disk – Unrecognized file system (-69846)

Related Question