Fw: [hfs-user] Problems with HFS+ empty volume...
Mon, 8 Apr 2002 09:33:46 -0700
> 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
> bigger would not
> particulary help in space-saving, would it ? In case of a CD of 650MB
> 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
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
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
> 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
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
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.