On Mar 9, 2011, at 7:35 PM, Dan Shoop wrote: > > On Mar 9, 2011, at 3:23 PM, Chris Murphy wrote: >> >> Except it is officially advised for moving Time Machine backups. So if it's >> good enough for moving a Time Machine backup.... > > It just means that it works for the filesystem metadata and functions used by > Time Machine. Doesn't mean it work for anything else.
Not just metadata and functions, all data and all executables that Time Machine backed up in the first place. I think a Finder copy is adequate for backing *data* portions of drives. We'd have serious problems if that were not the case. >> And an even larger sample size exists if filesystems other than jhfs+ are >> considered. RAID 5/6 are common with ext3, ext4, XFS and other file systems >> without anyone suggesting RAID 5 in particular is known for itself >> increasing the incidence of silent data corruption. > > Sorry to be blunt: What rock have you been under? You are conflating a higher incidence of silent data corruption with a known deficiency with RAID 5/6. They are not the same thing. Feel free to repeat yourself, though. > >>> >>> On Mar 6, 2011, at 8:04 PM, Chris Murphy wrote: >>> >>>> FWIW, Carbon Copy and Disk Utility copy (not sector copy) duplicates of >>>> volumes are not identical to the original. >>> >>> In the case of CCC this is incorrect. If you're not seeing this behavior >>> you are either using it impropperly or have an older version. >> >> CCC is not rocket science. I have a new version, it does not produce >> identical copies of all files in all cases. > > Since Backup Bouncer demonstrates it does, to what are you referring? hfsdebug indicates the original and cloned/copied files are not the same. With Time Machine restores, they are. > >> While the cloned system was perfectly functional, at a file system level >> they were not *identical* to the original, which is a very specific meaning. > > Again, in what way? Data stored in attributes was restored into the data fork. Storage requirement for files doubled to quadrupled. That is not identical to the original. >> Disk Utility is using asr. It does *not* restore or copy files identically >> to the original. > > No, disk utility and asr are quite different but perform a similar operation > using different code and operations. Watch a sc_usage or dtrace of each and > you'll see they're operating quite differently. I have watched Disk Utility while doing disk to disk copies and the only process it spawned was asr. Only asr was producing file system usage to the target drive. Chris Murphy _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
