Hello,
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 space at the cost of performance. Thanks for the info - I wasn't even aware that allocation block size would affect the performance... and for a CD where space saving in HFS+ 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 bit.
Thanks for the insider info - it's quite fascinating to note which factors and design considerations do play a role in developing a FS format ....
Regards, Nandini