I Wrote:
In general, if you're mastering CDs, the physical sector size will be 2048 bytes per sector. You might as well make the allocation block size and clump sizes 2048 as well. That way, one sector is one block, and the math is a little easier. On Mac OS X, performance may be slightly better if the allocation block size is 4096 (the same as its VM page size); of course you'd only do this if you can fit all of your data in 4KB allocation blocks.
On Saturday, April 6, 2002, at 04:50 AM, Entwicklung wrote:
It's true that the math is a little easier but making the allocation block bigger would not particulary help in space-saving, would it ? In case of a CD of 650MB there isn't much of space-saving in case of HFS+ anyway but after reading the Specs and browsing a number of websites I came to the conclusion that my allocation block size should be 'as small as possible and as large as necessary'.
If there is any overall savings, it would only be a few hundred kilobytes (due to a smaller volume bitmap). It might actually take more space if you had lots of small files (due to rounding up to whole allocation blocks).
The point was more that if you're already aligning the data to 2KB boundaries (for performance, or because you're making a hybrid CD, for example), there isn't any point in using a smaller allocation block size. Remember that the CD driver will have to read entire 2KB blocks; if allocation blocks aren't aligned on sector boundaries, it will end up having to read one or two sectors, extract just the relevant data, and copy it for the filesystem (which may have to copy it again to user space). The performance degradation is more noticeable on writable media, where a simple write turns into read-modify-write. But it does add up for read-only media.
If you're going to have an HFS wrapper, it would be a good idea to align the start of the embedded volume on a sector boundary. You can do that by increasing the allocation block start in the wrapper's MDB. FYI, older versions of Norton Disk Doctor will incorrectly complain about such a volume.
In case of HFS I don't have have a choice but for HFS+ it shouldn't be a problem setting the block-size to 512 even for images greater in size than 32MB, should it ? I thought that was the major improvement of HFS+ over HFS.
The allocation block size can be 512 for volume sizes up to 2 terabytes.
When we were developing HFS Plus, we sampled the hard disks of a variety of users. We recorded the size of every file on their (HFS) hard disk. We then computed the space savings for various allocation block sizes. There was a definite "knee" where further decreases in allocation block size yielded relatively little additional space savings. That knee was centered at about 4KB, extending to 2KB or 8KB depending on the primary use of the computer. I was personally surprised at that result; I assumed we'd continue to see noticeable savings all the way down to 512 byte allocation blocks. As Mac OS X becomes more widely adopted, the distribution of file sizes will probably change and move the "knee" a bit.
When we first shipped HFS Plus in Mac OS 8.1, we varied the default allocation block size from 512 to 4KB, depending on total volume size. The cutover to 4KB allocation blocks was for volumes 1GB or larger. Just before Mac OS X came out, we decreased the cutover point so that volumes 256KB and larger would use 4KB allocation blocks (because early versions of Mac OS X had a definite performance gain with allocation blocks that were a multiple of 4KB; the difference is less in current versions).
Later, in Mac OS 9.1 or 9.2, we added a default allocation block size of 8KB for volumes 220GB or larger. It turned out that the size of the volume bitmap was becoming a significant factor in writing performance (specifically, allocating space to files). When the size of the bitmap got close to or exceeded the size of the disk cache, allocation performance slowed dramatically. It also tended to push user data out of the disk cache, leading to a subsequent reduction in hit rates. Of course this won't affect read-only media, but it may be of interest for people putting HFS Plus on writable media.
-Mark