Block Count not correct?

[Grieverheart]

I created a drive with 10000mb, and looking at the device block count, it's reported as 20480096. The actual file size in bytes of the image is 10485825536. If I divide this by 512(block size), I get 20480128. So it seems that 32 blocks are overcommitted? Is this for protection?

Also, perhaps not related to Disk Jockey, but I formatted another image file I created myself using dd and the Drive Setup 1.7.3 from my Quadra, and it reports the correct size of 20480000 blocks (I created with bs=1m and count=1000*10), but when I count the actual blocks reported by the partition maps, I end up with 20480001 blocks (the last partition starts at block 20479991 and is 10 blocks big, an Apple_Free partition). Why is there a discrepancy of 1 block here?

[OneGeekArmy]

Regarding your first point, the additional 32 blocks are on purpose. They're there to help tools based on the sdFAT library, chief amongst them BlueSCSI. Alignment to 32-bytes boundaries is required to prevent performance issues. Previously, BlueSCSI users creating images with DJ were receiving messages in their devices' log warning of potential performance issues when the byte count of the image was not an exact multiple of 32. So now, DJ is rounding up the byte count systematically. Would you have a case where this presents an issue? I could make the rounding a setting that can be turned off if it's a problem.

As for your second question, I do not know. But my guess would be that Drive Setup had to make decisions based on what it thought the physical hard drive geometry was, and that it somehow ended up with a block too many (which is silly in these times of direct access to the whole surface of a storage medium). Or, and it wouldn't be the first time, it's an off-by-one error in Drive Setup. There's another case for this in the way hard drives for the Apple II are formatted: they should be able to support up to 65536 blocks (numbered from 0 to 65535) but the Apple formatter only creates 65535. But as I wrote, I don't know and all this is pure speculation on my part :)

[Grieverheart]

Thank you very much for your reply. That clears it up. As I mentioned in another question, I'm just trying to understand how things work. I'm not having any problems caused by the padding itself, so you can go ahead and close the issue.

On the number of blocks limit being 65535, I think that can be understood as it's using just 2 bytes to store the number of blocks, and the largest 2-byte number is 65535. But out of curiosity, I can test if the one-off problem is present for different sizes.

[OneGeekArmy]

For the block limit part, you're right and I explained badly. I just looked in my notes since it's been a while since I wrote the ProDOS partitioner for DJ. DJ creates a partition and sets its size as 0xFFFF (65535). When presented to an Apple II, the machine works as expected.

However, an actual Apple II using the Apple formatter, will create a partition 0xFFFE in size for reasons unknown (but most likely a bug). This is a problem for things that require every single byte to be available, like the Action Replay disk image.

SCSI hard drives for the Apple II being a bit of a rare luxury item, I guess this all went fairly unnoticed at the time.