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.... http://support.apple.com/kb/ht1427 Not that *I'd* advise it, but Apple seems to find it adequate. But that's all it is, is adequate. > 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. I have clients with them and they've lost drives, and no data, and no data corruption. 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. > > 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. 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. > 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. >> 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. Some files are too big to be entirely compressed and saved into extended attributes, so some of that info is put into the resource fork. But first it goes into attributes then it the rest goes into the resource fork. > >> 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. > >> 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. > >> When duplicated in any way other than a Time Machine restore or sector copy, >> these files are extracted from the Attribute File, decompressed and resaved >> as normal data fork files. They double or quadruple in size. On a recent >> restore this ended up making out for about 2G worth of difference. > > Again, false premise, false conclusion. http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3 "Though the Mail executable has a zero file size, it does have some extended attributes:" > > > 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
