PS2 APA partition size 16MiB

Berion

Berion

Developer
How is this possible in the first place? I was sure that in specification, size can be minimum 128MiB but when I choose formatting HDD in uLE, which is limited by HPA to 768MiB (I was curious what will happen), it creates "__mbr" and "__net" in standard 128MiB size, but the rest are equal 16MiB. So in standard partitioning scheme, minimum size should be 2GiB for all base partitions in standard sizes. Can anyone explain this?

ps2_apa_16MiB.jpg
 
I'd guess it's a bug - no one tested a HDD that small. The code does a lookup of what the max partition size on a HDD can be, and that is calculated from the total size of the HDD. I'm guessing it is returning 16 MB for that. It can still make partitions larger than the max partition size, it just uses sub partitions to make it up. But since the first two partitions took up most of the HDD space, it's either failing to make sub partitions for the others, so bailing on that and leaving you with partitions that are only 16 MB in size, OR it's just setting the partition size to the max partition size and only using that because it's less than the smallest size on the list of sizes it uses. (Or maybe even a combination of those two.)

Probably. :D

Also, the base partitions aren't set at 2GiB (and the minimum size is 128MiB), they kind of go up in size as it creates them, from a list of set sizes (128MiB, 256MiB, 512MiB, 1GiB, 2GiB, 4GiB, 8GiB, 16GiB, 32GiB). It starts with __net, so __net gets 128MiB, __system gets 256MiB, __sysconf gets 512MiB, __common gets 1GiB. (This is if using wLE to format the HDD, other things can use different sizes.)

The code wLE is using to format a drive is in the PS2SDK, so this would be a bug in the sdk rather than wLE. I would expect it to create __mbr at 128MiB, __net at 128MiB (made up of 1 primary partition and 7 sub partitions all 16MiB), __system at 256MiB (made up of 1 primary partition and 15 sub partitions), __sysconf at 256MiB (it tries to create it at 512MiB but runs out of space so leaves it at 256MiB, so 1 primary partition and 15 sub partitions), and fail entirely to create the __common partition as there would be no space on the HDD left. But yeah, there shouldn't be any partitions smaller than 128MiB.
 
Oh yeah, I see where it's happening. It's not exactly a bug, it's more that no one considered that the max partition size would be less than 128MiB. Which I could see why, the official HDDs were 40GiB in size, and that gives a max partition size of 1GiB.

If you're interested, it's in lines 338 and 339 of hdd_fio.c. The check there sees if the new partition size it has calculated is bigger than the max partition size, and if so, sets the size to be the max partition size. It starts out at 128MiB, and then right before that check, doubles the size (so the check would be against 256MiB). Usually that would be fine, but in the case of a 16MiB max partition size, it defaults to that. Every partition after the first one gets created at that size.
 
I have dig a little more and not all tests covering this theory. :) Anyway, all uLE/wLE and PFS Shell sharing the same problems.

If HDD size is X then partitions after __net will be Y (missing 2GiB threshold, why?):
  • For 128MiB+n up to 512MiB > 8MiB
  • For up to 1GiB > 16MiB
  • For up to 4GiB > 32MiB
  • For up to 8GiB > 64MiB
  • For 10GiB > 128MiB (but still cannot create new partition larger than 128 or just 128)
  • For 16GiB > starting to behave normally
None of the tools allowing me to create 128MiB partition (or larger) if earlier partition is smaller than 128.

FMCB installing fine and HDDOSD starting without problems on 32MiB. However, HDDOSD shows 0 free space and uLE doesn't see that space is end (it overwriting data o_O if copying data oversize the amount of free space). Crazy. :)

But this little experiment proves that we could alternate the APA specs. Support for i.e 8MiB chunks would save a lot of space wasted on games and system partitions.

Thank for code lurking. ^^
 
Yes, pfsshell uses the same code from the PS2SDK that wLE does (altered a small bit to run on a PC, but mostly the same).

And yes, as it works now, it won't create a partition larger than the max partition size when formatting a device. So you won't get any 128MiB partitions unless the HDD is over 4Gib, 256MiB partitions unless the HDD is over 8GiB, 512MiB partitions unless the HDD is over 16GiB, or 1GiB partitions unless the HDD is over 32GiB.

Your experiment just shows that the system is able to read PFS partitions that are smaller than 128MiB (which is surprising). But it also shows that it can't reliably write to those partitions. Changing it to be able to do it with smaller sizes is I suppose technically possible, but *every* bit of software that reads/writes to the HDD would have to be updated to understand it - including the HDDOSD. Not a small task.
 
On 10GiB size I still cannot create 128MiB partitions.
On 16GiB size, I'm start to be able create whatever I want, i.e 10GiB partition (in summary of course, but in UI in uLE it is shown to user as one).

Those tests are time consuming so I didn't tested all thresholds but even on those above, there are some strange math breaking. ;p I'm not digging more as my setup satisfy me but I just point that we still don't fully understand this occurrence.

Sure, a titanic work, but at least is possible. :)

- - -

PS: If someone want to know how to limit space via hdparm:
Code: 
hdparm -N p33554432 --yes-i-know-what-i-am-doing /dev/sdx
Code: 
128MiB     134217728   / 512 = 262144
256MiB     268435456   / 512 = 524288
512MiB     536870912   / 512 = 1048576
1GiB     1073741824   / 512 = 2097152
2GiB     2147483648   / 512 = 4194304
4GiB     4294967296   / 512 = 8388608
8GiB     8589934592   / 512 = 16777216
16GiB     17179869184   / 512 = 33554432

If for some reason Linux will froze the device, just suspend the computer and wake it.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top