Post by: Bomb Bloke on October 14, 2008, 09:55:00 PM
Nevertheless I'm pretty sure the code is already correct in terms of the initial starting value I have there. But according to your statements, you find that the cluster size does not change from 16kb to 32kb when you cross the 256gb mark - I find that a little problematic to rationalise, considering that it worked fine in my tests, and people with larger drives then I own have confirmed it correctly jumps to 64kb clusters when you break the 512gb mark.
Can you confirm that XBP 1.1 uses the incorrect cluster size for all partition combinations with your drive? If so, provide some details on your BIOS, drive make, and console version.
If it only stuffs up when crossing the 1TB mark then I reckon there's gotta be an overflow in there somewhere, but I'm not sure where... Heck, I don't even know how many bytes a ULONG takes up these days. Is it still four? Hope so, should be an easy fix if that's the case.
Mind you, I still recommend a split partition setup. To my mind 128kb per cluster is wasteful to the extreme. A 32kb and 64kb cluster split would be vastly more efficient.
There's also the possibility even if XBP does decide that 128kb is the cluster size it's gonna format with, that doesn't mean 128kb clusters will work. You won't know for sure until you get 1tb of data on there.
Furthermore, another guy with a 1.5tb drive had trouble after the format was done (even though he went with a split setup). Though maybe I should get him to take a look at this, perhaps it'll offer some insight on his case as well.
Post by: Bomb Bloke on October 15, 2008, 03:05:00 AM
I assume a ULONGLONG is something like eight?But, the thing that gets me is this:
If "compare" is overflowing, then the "while" condition should always be true and the program would enter an infinite loop (that is, the X-Box'll crash if you try to define a 1tb+ partition).
If the LBASize function wants to return a ULONG, then there should be no infinite loop but if you try to define a partition 1tb+ the cluster size should drop down to 16kb.
Neither of these things are happening... But yeah, there's certainly room for an overflow error there.
Post by: emailchaos on October 15, 2008, 01:19:00 PM
QUOTE
If "compare" is overflowing, then the "while" condition should always be true and the program would enter an infinite loop (that is, the X-Box'll crash if you try to define a 1tb+ partition).
From what wildonrio just mentioned, the xbox does freeze, which confirms the infinite loop, I believe.
QUOTE
If the LBASize function wants to return a ULONG, then there should be no infinite loop but if you try to define a partition 1tb+ the cluster size should drop down to 16kb.
Is the LBASize a ULONG? What is its defined type? If it is a ULONG, then we have another problem, because the LBASize itself could be overflowing...
Post by: Bomb Bloke on October 15, 2008, 05:32:00 PM
QUOTE(emailchaos @ Oct 16 2008, 03:55 AM) 
Is the LBASize a ULONG? What is its defined type? If it is a ULONG, then we have another problem, because the LBASize itself could be overflowing...
Unlikely. "compare" can only increment so long as it's less then LBASize. If LBASize is hitting an overflow, it becomes impossible for "compare" to do the same; hence no infinite loop, and no crash.
Which is all another way of saying "I can't find where LBASize is defined, I think that function is part of the XDK itself and it'd take me too long to hunt it down".
Post by: wildonrio on October 15, 2008, 06:38:00 PM
QUOTE(emailchaos @ Oct 15 2008, 06:36 PM)
Ah, yes, that makes sense.
I'm interested in knowing if the overflow fix allows 128k cluster sizes. Let me know!
Ok I used ULONGLONG instead. Good news is, it actually formatted with 128k clusters! Bad news is, the partition is labeled on the dashboard (XBMC) as "Unavailable". As far as FTP, the F partition shows up but nothing will transfer to it without an error. Getting closer! What next?
Post by: emailchaos on October 15, 2008, 06:46:00 PM
If someone can post the code snippet of where the auto-calculated cluster size is used, I will take a look. Hopefully it's not an XDK function, otherwise we'd have to modify the XDK source!
Post by: Bomb Bloke on October 15, 2008, 07:16:00 PM
The formatting command goes along these lines:
QUOTE
status = XapiFormatFATVolumeEx(&partition_str[g_iCurrentPart], g_iClusterSize << 10);
Where "status" is an int (the XBP packs on X-Bins include full source, by the way). Don't think the bitshift is causing an issue here 'cause if it was 64kb clusters wouldn't be working either.
I'm pretty sure that function is bundled somewhere in the XDK library files, but I've no idea as to how to extract them. Plus there's a good possibility that the issue isn't with the code, but rather another limitation of FATX (such as the one that warrants the use of XBP in the first place).
Seems far easier to me to prevent users from defining partitions 1tb+ and call 2tb the final X-Box drive limit.
Post by: ldotsfan on October 16, 2008, 06:47:00 AM
QUOTE(Bomb Bloke @ Oct 16 2008, 08:08 AM)
Unlikely. "compare" can only increment so long as it's less then LBASize. If LBASize is hitting an overflow, it becomes impossible for "compare" to do the same; hence no infinite loop, and no crash.
Which is all another way of saying "I can't find where LBASize is defined, I think that function is part of the XDK itself and it'd take me too long to hunt it down".
LBASize is defined in partition.h
CODE
typedef struct
{
UCHAR Name[16];
ULONG Flags;
ULONG LBAStart;
ULONG LBASize;
ULONG Reserved;
} XboxPartitionTableEntry;
Post by: run088 on October 16, 2008, 01:52:00 PM
I am 100% positive I built it correctly so I am positive there is a problem with the 64k partitions.I was going to try 1 big partition with 128k and see if the results were different but you all are saying that you all are having problems there to.
Post by: Bomb Bloke on October 16, 2008, 05:06:00 PM
QUOTE(emailchaos @ Oct 17 2008, 02:49 AM)
Now that's interesting. So I wonder where LBASize is being used, and I wonder why LBASize didn't mess up the cluster detection loop, since I would think there would be an overflow problem.
Changing LBASize to a ULONGLONG may have a positive effect...
Changing LBASize to a ULONGLONG may have a positive effect...
It confuses me too, but if XBP says it's gonna use 128kb clusters and then proceeds throughout the formatting process, then the size detection code has done it's job correctly - nothing more to mess with there.
QUOTE(run088 @ Oct 17 2008, 04:28 AM)
For what it is worth I am positive I used 64k on a 1.5tb split between f&g and data corruption occurred after passing 512 gigs.When I first tried the app it froze everytime until I formatted once with an older build on a new install then the new app seemed to work fine.
I am 100% positive I built it correctly so I am positive there is a problem with the 64k partitions.I was going to try 1 big partition with 128k and see if the results were different but you all are saying that you all are having problems there to.
I am 100% positive I built it correctly so I am positive there is a problem with the 64k partitions.I was going to try 1 big partition with 128k and see if the results were different but you all are saying that you all are having problems there to.
While it's certainly a problem, I'm not thinking this is related anymore...
My current theory is that XBP 1.1 never formatted your drive. You first formatted with the older build (which used 32kb clusters), then with 1.1 (which froze the first time... and simply didn't work the second time).
Beats me as to why. I suppose the first test would be to try a few different layouts with 1.1, see if the drive layout changes correctly with each consecutive format.
I know 64kb partitions work. Heck, wildonrio here can vouch for that.
Post by: Bomb Bloke on October 17, 2008, 01:49:00 AM
Edit:
Actually looking in a bit further detail I see that anything's possible. It could well even be the problem (though I'm still somewhat doubting it). In fact changing that to a ULONGLONG could well break the program, but...
... Well, one way to find out for sure. I'll compile a new build
Post by: run088 on October 17, 2008, 04:59:00 PM
I did think however this setup would be the best way to save space making 1 partition to the 512g 32k limit.It will most likely be some time before the 2tb hdds hit the market and alot longer than that before anything bigger hits the market so we really got some time before the 128k will ever be needed.128k will be what is needed for drives from 2tb to 4tb.
Post by: Bomb Bloke on October 17, 2008, 07:23:00 PM
QUOTE(run088 @ Oct 18 2008, 07:35 AM)
I can confirm that the xbox crashes when it sees the 128k partition.I went ahead and split mine again with f of 504gigs at 32k and g at 900gigs with 64k.It shows as more in xbmc and that worries me a little.xbmc f=516gig g=906gig The only way to find out is to fill it completely or leave 4gigs worth or slack in the partition and forget about it.
Hmm, that ain't so good. If I were you I'd format once more making F a little lower - You really want it to display at less then 512gb to be on the safe side.
Scratching my head as to why it'd do that. Actually, might be well worth checking what a few other dashboards report before formatting again.
QUOTE(run088 @ Oct 18 2008, 07:35 AM)
I did think however this setup would be the best way to save space making 1 partition to the 512g 32k limit.It will most likely be some time before the 2tb hdds hit the market and alot longer than that before anything bigger hits the market so we really got some time before the 128k will ever be needed.128k will be what is needed for drives from 2tb to 4tb.
Quite correct.
Post by: Milleman on November 25, 2008, 03:35:00 AM
Just bought a 1.5 TB drive and the XBP 1.1 insists on formatting the the large partition with only 32kb clusters. anyone that got a patched XBpartitioner that will format using 128 kb clusters?
/Mill
Post by: Milleman on November 25, 2008, 09:40:00 PM
Reading the information at the following link:
Windows XP Professional File Systems Overview
...gives me the information that the FAT32 (FATX?) uses the following cluster size convention:
FAT32 file system cluster sizes
===============================
Partition Size ----------------- Cluster Size
0M to less than 260MB ----- 0.5k (512 bytes)
260MB through 8GB -------- 4k (4,096 bytes
8GB through 16GB ---------- 8k (8,192 bytes)
16GB through 32GB -------- 16k (16,384 bytes)
32GB through 2TB ---------- 32k (32,768 bytes)
===============================
If there isn't a cluster redesign in the FATX, a 32k cluster size would therefore be able to handle upp to 2 TB disks. But why are partitions over 512 GB, using 32k cluster size, getting corrupted then?
Post by: Bomb Bloke on November 26, 2008, 02:09:00 AM
Hence the maximum partition size is tied to your cluster size. The default of 16kb (2^14 bytes) multiplies out to 274,877,906,944 bytes (2^38).
Divide that by a gigabyte (2^30) and the final figure is 256 (2^8) gb.
Now, there's nothing stopping you from attempting to create a partition larger then 256gb using 16kb clusters. Catch is, as soon as you actually attempt to put more then that amount of data on there, you run out of addressing space, the file system overflows, and whoops! The file index table just got overwritten...
I dunno if this bug also exists in FAT32, but I've never heard it mentioned. So why do they bother to change the cluster size for larger drives in that case?
Well, the file index table keeps track of clusters, but the smaller your clusters are, the more of the things you have - and hence the bigger your index has to be. Attempting to index 2tb worth of data using half kilobyte sized clusters would require 4gb, while a 32kb cluster size reduces that figure to just 64mb.
I think NTFS likes to use 4kb clusters regardless, which is fair enough. There comes a point where drive efficiency will be taking a bigger hit due to huge clusters then it'll be gaining from having a small index.
Post by: Bomb Bloke on October 04, 2009, 10:40:00 PM
We'll probably never know whether wildonrio did that last test.
Any attempts to do a format with 128kb clusters result in a corrupt partition.
128kb clusters are still wasteful unless you want to install a drive larger then 2tb.
Post by: Clockface on December 20, 2009, 06:50:00 AM
Thanks for any answers.