(I posted this on the sticky LBA48 thread, but thought I should post here too)
My thoughts on ~280GB limitation:
As I've said from the beginning, LBA48 allows for partitions up to about 2TB, but I suspect that there are FATX limitations that make the max partition size smaller. But, it should be possible to create as many partitions you like - each smaller than the FATX limitation - with no problems. The LBA48 code supports more than just partition6/partition7 (F:/G:). I forget the number - maybe 4-6 more partitions are allowed in the current code (this could be increased - up to (I think) either 10 or 20 partition limit (per drive) in the kernel).
I suspect that the FATX limitation is in the FAT (File Allocation Table). This table is at the start of the drive, and gets initialized at format time. As you add files, the space they take up gets marked in the FAT.
There are at least 2 different 'types' of FAT tables on a FATX system (FATX16/FATX32). One is for smaller partitions, another for larger. At the time of formatting the partition, the FAT 'type' is chosen and the FAT table is initialized with entries for each 'cluster' on the partition.
So, the FAT table must be of the right 'type', and must have enough entries for (total size of partition / size of 'cluster').
According to this page:
Xbox Linux FATX infoa 'cluster' on the Xbox is always 512 bytes. So, the FAT table must be large enough to hold (total partition size / 512) entries. Each FATX32 entry is 4 bytes (32bits), so the FAT table byte size would be: ((total partition size / 512) * 4) bytes.
If someone has a way of dumping a formatted disk, they could confirm that a newly formatted FATX partition on a large (> 280GB) drive is large enough for the partition. Keep in mind that it's
possible that the utility/utilities used to format the drive are at fault - not an underlying filesystem problem. This would be the best scenario, since that can easily be fixed. I haven't read the entire thread: is there a common format utility used in all cases of '
corruption'? Keep in mind that some format utilities (Slayer's, for example) make use of EvoX's own format code (so multiple utilities could really all be the same one).
Another possibility: the max size of a 'cluster #'. On older FAT systems, as drives grew larger, the size of a cluster was increased. Part of the reason for this was that there was a max cluster # size (16 bits, I think, so 65535 max clusters). If cluster sizes are made larger, then 65535 clusters represents a larger amount of hard drive space.
The Xbox-Linux doc I referred to above says that the cluster size is fixed @ 512 bytes. Maybe we're hitting a max cluster # limit. If so, then
maybe it'll be possible to figure out how to get FATX to use a larger cluster size. I really doubt this, but since (I think) there are some 'undefined/unknown' fields in the FATX partition header, we may find that one of these values can be tweaked to use larger cluster sizes.
The negative side for larger cluster sizes means that the minimum file size now increases (a 1 byte file on FATX now takes 512 bytes of space - it would take more space if the cluster size is bigger). This means that if you've got lots of small files, you end up wasting lots of drive space. This is the big trade-off on increasing cluster size. But, it's what people have lived with on older FAT systems - we may have to live with it on FATX (assuming we can figure out how to make it use larger clusters).
My job has kept me
very busy lately - no real time for any Xbox experimentation. I also don't have a drive large enough to reproduce these problems (I have a 200GB which works fine). I'll try to offer input/help on this issue, but I can't promise that I'll be able to dedicate much time on it.
I hope this is helpful.
- Paulb
Author
Topic: Anybody Filled A 250gb+ F: Drive? (Read 142 times)