...I'm not all certain where you're headed...
Well, it's a comparison of the number and size of items in
/sbin and
/bin on the source with the number and size of items in
/sbin and
/bin on the clone. As far as I can tell, they're identical.
Yet the number of 512-byte blocks used by those files is wildly different between the source and the clone:
/Volumes/HD/sbin:
total 5640
/Volumes/HDx/sbin:
total 14728
/Volumes/HD/bin:
total 8640
/Volumes/HDx/bin:
total 20144
So somehow, identically-sized files are occupying a larger number of blocks on the clone.
BTW, i'm wondering now if this all isn't simply due to SL's new "compressed storage" feature in HFS+. The boot volume maintains a compressed version... but a restore operation will expand the data onto the backup volume.
This stuff is largely over my head, but a perusal of the Installation page from
Mac OS X 10.6 Snow Leopard: the Ars Technica review provides some interesting details about Snowy's compression techniques, including this tidbit:
You may be wondering, if this is all about data compression, how does storing eight uncompressed bytes plus a 17-byte preamble in an extended attribute save any disk space? The answer to that lies in how HFS+ allocates disk space. When storing information in a data or resource fork, HFS+ allocates space in multiples of the file system's allocation block size (4 KB, by default). So those eight bytes will take up a minimum of 4,096 bytes if stored in the traditional way. When allocating disk space for extended attributes, however, the allocation block size is not a factor; the data is packed in much more tightly. In the end, the actual space saved by storing those 25 bytes of data in an extended attribute is over 4,000 bytes.
I wonder if the expansion of the compressed data is occurring because the restore operation is making a file-level copy of the source rather than a block-level copy? (Since your target was smaller than your source, a block-level copy wouldn't have been possible; also, you'd've needed to be booted from a third volume, since both source and target need to be unmountable for a block-level copy using ASR.) (Which leads to the following question:
were you booted from a third volume? If so, was it a Leopard volume?)
