Fw: [hfs-user] Problems with HFS+ empty volume...
Thu, 11 Apr 2002 11:49:50 +0200
> 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.
I get it... it's ultimately a question of whether one wants to save a bit of
at the cost of performance. Thanks for the info - I wasn't even aware that
block size would affect the performance... and for a CD where space saving
is anyway only a little, I guess performance does play an important role.
> 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.
How much of effort is involved in having a HFS-Wrapper ? Right now I've just
initialized a pure HFS+ volume without a HFS-Wrapper.... It's working now
btw. ! :)...
>From the previous mailing-list responses I had come to the conclusion that a
wrapper would be necessary since older Macs would then say - The files
cannot be read because it's in HFS+ format -
or something similar. And in case of having no wrapper it would ask if the
CD has to be formatted.
I guess I could also decide not to have a wrapper since if a user decides to
format a CD and clicks 'yes' it's pretty obvious that no data can be
recovered from the disk after formatting a CD-RW for eg.
If I were to have a Wrapper does it mean that I'd have an external HFS
volume in which a HFS+
volume is embedded ? If that is the case - would allocation block no. etc
inside the embedded volume vary relative to the start of the embedded volume
? Do I need a partition map for this? (stupid question probably but was just
wondering if these wouldn't be considered as 'two' volumes)
> 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
Thanks for the insider info - it's quite fascinating to note which factors
considerations do play a role in developing a FS format ....