Fw: [hfs-user] Problems with HFS+ empty volume...

Mark Day mday@apple.com
Mon, 8 Apr 2002 09:33:46 -0700

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 

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.