Hi Simon,
SB> There is a limit on the maximum size of any particular disk of 4 billion SB> (2^32) * the block size, or 0xFFFFFFFF * sbBlkSize. If sbBlkSize is SB> 0x0200 as you say then the limit is about 2 Gb. SB> I'd guess that to get around this either DVD's use a larger block size SB> (0x2000 would adequately cover the 4.5Gb physical maximum on a DVD) or SB> use HFS+ or some other system.
As far as I know, HFS+ volumes also have the same Device Descriptor Block in sector 0. More, one could easily have a device with a first partition in HFS and a second in HFS+. This block size is only used in this DDB and in the partition table (the fourth unsigned long).
Therefore, it would not be that difficult to switch to another block size just to manage the DDB and the partition table. One would in that case put the beginning of the partition table, not in sector 1, but in block 1 (that is, sector = block size / 512).
SB> Remember the only real reason why it is bad to use large block sizes is SB> the wasteage that occurs with small files. On a DVD you typically have SB> less than 20 files, some of which are huge so the lost space is minimal.
This block size doesn't have anything to do with the allocation block/cluster size, that is with the size of the chunks used to manage the data space in the allocation bitmaps. As a matter of fact, HFS+ volumes frequently use 0x1000-byte blocks, but switch to 0x2000 for bigger disks (from 100GB, I think).
On the other hand, DVD are not only used to store movies and likewise big files, but also to store plain data files, when the size of a CD-ROM is not enough. For such volumes, keeping the allocation block size to 0x800 bytes is an advantage, in particular if you build hybrid data structures with an ISO/Joliet catalog pointing to the same data pool.