On Mar 26, 2012, at 9:54 PM, Nathan Sims wrote: > Thanks, Chris, for the very detailed writeup. > > I installed smartmontools via Macports, it works on the boot drive (Seagate), > but on my external drives (Maxtor and G-Drive) it comes up with the same > 'unsupported' error. Guess they don't support SMART.
The firewire bridge chipset in the enclosure doesn't support the full ATA command set. Which means it also won't support ATA secure erase either. But the problem disk is the boot disk, which is the internal disk, is my understanding. The external disk is for Time Machine, right? > $ sudo smartctl -a /dev/disk2s1 > smartctl 5.42 2011-10-20 r3458 [x86_64-apple-darwin10.8.0] (local build) > Smartctl open device: /dev/disk2s1 failed: Operation not supported by device > > The external drives are not the boot drive. If you have a brand new enclosure that does not support the full ATA command set, I would send the disk back for a refund or exchange when convenient for you. Use it for your purposes in the meantime. I find it borderline unethical that these chips sets even exist, let alone are sold to an unwitting public. But a return for this reason alone is perfectly legitimate. For a disk that's outside of the return window - I'd still be an ass|o|e and try to get a refund. Make them say no. > I've been using the new drive for a day now, working on the same projects as > before, and I've not come across any files that appear damaged or truncated. > Everything seems kosher, but I guess it depends on what TM does when it gets > a disk I/O error - skip the backup of that particular file? I did run Disk > Warrior on the suspect drive before doing the asr copy, and it found nothing, > a result which surprised me. Perhaps DW's rebuilding of the drive index was > the cause of TM's full backup? There's only enough information provided for me to speculate. I don't know exactly what I/O errors you received. The data affected could be an obscure system file that will rarely if ever be used. It could be a help document that will never be used. It could be an inactive customer project that you have no intent to use again, but next month you'll get a request for reprints... and you won't be able to open the file. The only way to know for sure, is a.) go through every file and check; b.) run smartctl -t long and see in a few hours with the -a flag if the test was aborted, and at what LBA. Then there are methods to find out what data is at that LBA, extract what you can, overwrite the LBA so the disk mechanism removes that sector from use, and then rerun -t long self-test, which will almost inevitably end up at another failure at another LBA. Rinse. Repeat. It could be a few sectors causing lots of problems. It could be hundreds or thousands of sectors. The facto you're geting I/O errors indicates it's some file the system is accessing pretty regularly though, I'd think. What that is, can't say. Disk Warrior only checks directory structures and a handful of certain file metadata. It does not check every sector of every single file. Pulling a hair out of my ass (i.e. a total guess) that the file system structures make up maybe 10% of the data on the disk. So Disk Warrior is not checking a lot. It's basically checking the card catalog for the library. It's not checking any of the books to make sure they aren't missing or have been damaged. As for what backupd does when the source disk reports an error - I don't know. Errors occur by sectors. If a disk can't recover a sector and reports an error back to the file system, the filesystem can't reconstruct the file completely. I don't know what HFS does in this case - use what it did get? Or does it fail the whole file? > > As much as I hate to, I guess I could zero the TM drive and start over with > it. Why? That's the only drive that might possibly have uncorrupted data on it. That's the drive to secure. Buy yet another new drive for backups if you don't have the space somewhere else in the meantime. That disk you should effectively make read only until you're certain all of your most important data is available, and not corrupted. Chris Murphy _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
