Hello Mark,
myVolHeader.lastMountedVersion=kHFSPlusMountVersion; // implementation version which last mounted volume
You should pick some other constant unique to your implementation. That way, if a bug is found in your implementation, other implementations can check this version to correct for the bug.
In my case I've reset kHFSPlusMountVersion to my own unique creator-code registered with Apple (it doesn't hold '8.10' in my case)
myVolHeader.folderCount=0; // number of directories in volume
That may be wrong. I can't remember whether the folder count includes the root directory.
The HFS+ TN says that it doesn't include the root folder.
myVolHeader.nextCatalogID=0x00000000; // next unused catalog node ID
That number should be at least 16 (the minimum ID for ordinary files and folders).
In case of HFS I just played around with these values and set this field to 0. This didn't affect readability in any way and my volume is a read-only medium so no further CNID's will be assigned. This was why I've set it to 0 for HFS+ too... maybe some extra check is being made in case of HFS+ so I'll change this to 16.
myVolHeader.encodingsBitmap[0]=0x00000000; // which encodings have been used on this volume myVolHeader.encodingsBitmap[1]=0x00000000;
You should probably set at least bit 0 of the first field. That corresponds to the MacRoman encoding, which is the fallback when other encodings don't work.
OK.. I'll do that
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.
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'. Do correct me if I'm wrong..... 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 only problem is that I don't have any utilities to create sample HFS+ images which I can cross-check my image with.... Disk Copy on my iMac with MacOS 9 creates only HFS-Volumes by default
In Mac OS 9, use Disk Copy to create a read/write disk image that is at least 32MB. That is the minimum size volume that Mac OS 9 will format as HFS Plus (though it should recognize smaller volumes).
I just tried this out ... It works fine for volumes >32MB. Thanks ! Btw. yesterday I also came across a software MacOpener 2000 which creates HFS+ images. After a large no. of searches this was practically the only cross-platform tool I came across which can supposedly read and write HFS+ volumes (not freeware however). I would have probably considered buying it if I hadn't got this bit of info from you.... but maybe someone else on the list can make use of it after all...
Regards, Nandini
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
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
-
Entwicklung -
Mark Day