On Mar 9, 2011, at 3:23 PM, Chris Murphy wrote: > > > On Mar 9, 2011, at 11:19 AM, Dan Shoop wrote: > >> >> On Mar 6, 2011, at 9:50 AM, Neil Laubenthal wrote: >> >>> Sometimes you can't repair the disk if you're booted from it. Here are a >>> couple things to try. >>> >>> 1. Backup the data portion of the drive using Finder Copy >> >> This is never an advisable way of backing up files. Many types of files are >> invisible and many types of files the Finder just is programmed not to >> display. Copying an entire folder should copy any invisible files contained >> within it but there's no assurance when viewing through the Finder that >> you're ever grabbing everything. > > 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. >> The integrity of the data with files after any issues such as these may be >> suspect, especially if the fileystem was on a RAID5 which is very well known >> for silent data corruption. This is why RAID5 should not be used. > > OK that's possibly a whole separate thread for qualifying such a statement. > Apple has a supported product that uses RAID 5. Yeah, and so do a lot of companies and software Doesn't make it safe. RAID5 has always been a set of trade offs. These days with cheap disks raid5 fails due diligence. > I have clients with them and they've lost drives, and no data, and no data > corruption. That you know of. Silent data corruption is just that. And yes, drive failover works, so long as the data was valid the first time. > 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? >> >> 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? > 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? >> Dik Utility can copy files or block copy. In each case it preserves properly >> but asr should be used instead. Note that in some case it may uncompress >> compressed files depending on the target and operation type, but this is not >> an issue. If it is, use asr. > > 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. >>> And most frequently what's not restored correct is File Security >>> Information - the consequences of which I don't know. And then also >>> Attributes. A huge percentage of small system help and programs (the small >>> BSD programs) are not stored anymore in the data fork. Apple is compressing >>> them, and putting them in the Attribute File, >> >> Um... no, not actually accurate. It's just using a named resource fork of >> the file for storage. > > hfsdebug bashbug > > # Data Fork > logicalSize = 0 bytes > # Resource Fork > logicalSize = 0 bytes > # Attributes > <Attributes B-Tree node = 48200 (sector 0xdc0f0)> > # Attribute Key > keyLength = 46 > pad = 0 > fileID = 1051051 > startBlock = 0 > attrNameLen = 17 > attrName = com.apple.decmpfs > # Inline Data > recordType = 0x10 > reserved[0] = 0 > reserved[1] = 0 > attrSize = 3075 bytes > > Zero bytes resource fork. Zero bytes data fork. The data is compressed and > inserted into the attribute file. There are no "resource forks", only data and named forks. Named forks can, if they fit, live in a Attributes B-Tree where other named forks, such as the file attributes fork (a specific named fork), also live. >> >>> a component of HFS just like the Catalog File. >> >> No, incorrect. No file data goes in any of the filesystem catalogs or >> b-trees, all file data is stored in the file, though "file" here will >> include [old style] resource forks and other named forks. > > Some larger files contain data in resource forks as well as the attribute > file. All you have to do is use hfsdebug on some sample files and you will > see large amounts of data in the attribute file that are not attributes. > These are executable command line programs. /usr, /bin, /sbin are full of > these files. Again I argue that you're saying the same thing but using the wrong nomenclature for the current OS implementation. There are no resource forks, just named forks and data forks. >>> So these files take up zero sectors on disk since they are stored in the >>> Attribute File. >> >> Again, no. > > Apparently you are unfamiliar with ls -ls and have not done this on /usr/bin. > Fully 1/3 of the executables there are taking up 0 sectors yet they are not > zero byte files. If you hfsdebug them, 0 byte data fork, 0 byte resource > fork, all is in the attributes file, the space penalty for which was taken > when the volume was formatted. It's not that they're taking up no data space, there is no data. Hence tools that measure data fork sizes show no usage. There is a compressed attribute fork. >> If you don't understand what you're doing I'm not sure why you're doing it, >> yet alone recommending it. >> >> The disk device is a logical block level representation of the device, each >> block, in order, represents the corresponding logical block number of the >> logical disk. >> >> The raw device is a physical block level representation of the device, each >> block, in order, represents the corresponding "physical" block of the disk >> device. This "physical" block is not actually the real physical block on the >> disk, but the disk's presentation of these blocks to the OS. The actual >> blocks on the disk are constantly being remapped as needed. > > Mac OS uses LBA. It does not access physical blocks in any event. > > >> You should not use raw devices for making disk images or backups, or just >> about anything other than low level forensic clones. And comparisons of them >> may vary between any two dd's of the raw device. >> >> The reason that a dd of the raw device is faster is because it is, very >> generally speaking though not quite accurate, performing a spiral read of >> the device which generally is the fastest since it represents the shortest >> head path travel on the device. > > This does not explain why /dev/sda on Linux which is block level, not raw, > has 6x the performance of /dev/disk0 which is block level, not raw. This is a > drive with zero bad sectors, there is no good reason why a /dev/disk0 block > level read would be so contrary to a spiral reading of the surface compared > to a raw read with /dev/rdisk0. The LBA to physical sector mapping would have > to be severely different. > > >> >> On Mar 8, 2011, at 12:03 AM, Chris Murphy wrote: >>> OK well, then it should be simple for you to explain why /dev/disk0 results >>> in 17MB/s read, and /dev/rdisk0 results in 107MB/s read, and on Linux >>> /dev/sda result in 107MB/s read which is the block level device and there >>> is no raw device created anymore. >> >> Indeed it is and the above should clarify that. On other unices (including >> linux) there still are raw devices. > > Abandoned with Linux kernel 2.6 - /dev/sda is *NOT* a raw device. Some Linux > distros let you create a raw like device using udev. This is not default with > Fedora which is the context here. > >> >> On Mar 8, 2011, at 4:27 AM, Markus Hitter wrote: >>> Mac OS X is designed to be comfortable, not neccessarily quick. Low level >>> performance is a field where Linux really shines. >> >> More than just comfortable, it's designed to be safe. It takes the "do no >> evil, cause not harm" philosophy. It performs read after writes and checks >> data. > > Evidence? This would be incredibly inefficient considering many drive > technologies have this capability built into them. > >> Linux, the whore that is is being just a kernel, doesn't do any of that >> because that's not the responsibility of a kernel, data integrity, that's >> the responsibility of the higher level systems. > > Absurd. File system support is part of the Linux kernel. Data integrity is a > primary feature of any file system. Of course it is the responsibility of a > kernel to maintain, not jeopardize data integrity. There are demonstrably, > unarguably superior safer file systems than jhfs+ - but this is not even > relevant because this was a block level read example - file system is > irrelevant at that level. > >> Linux is quicker because it's doing the bare minimum. It's not a good choice >> if you care about data integrity over speed. > > Sorry, ext3, ext4, XFS, the list goes on. You can have both speed and data > integrity. Linux btrfs file reads are faster than XNU /dev/disk0 block level > reads using dd where jhfs+ isn't even relevant - and that's an unstable file > system still being developed, not optimized for speed. Now it very well may > be the problem is with dd on XNU. > > > > Chris Murphy_______________________________________________ > MacOSX-admin mailing list > [email protected] > http://www.omnigroup.com/mailman/listinfo/macosx-admin -d ------------------------------------------------------------------------ Dan Shoop [email protected] GoogleVoice: 1-646-402-5293 aim: iWiring twitter: @colonelmode _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
