Print

[Bomb Bloke]

I could never work out exactly what "compare" stood for, but my best bet was that it dealt with the number of entries in the partition's cluster index table. Cluster based corruption is caused by having too many, but the larger the things are the less you need to fill the drive.

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.

[Bomb Bloke]

So a ULONG is four bytes... thanks for the heads up.    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.  

[emailchaos]

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...

[Bomb Bloke]

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".  

[wildonrio]

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?

[emailchaos]

Wow, could be one of several things.  Maybe the partition code is not designed to handle this cluster size.  Where is the auto-calculated cluster size being used?  I tend to think this is the case, if FTP cannot perform a simple file transfer.

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!

[Bomb Bloke]

I don't think I can do much more for it then that... Back when the initial testing for 1.1 was being done, we had the same issue (as already mentioned).

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.  

[ldotsfan]

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;

[run088]

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.

[Bomb Bloke]

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...

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.

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.

[Bomb Bloke]

Dunno, don't care. Take another look at that formatting line I quoted. As it isn't mentioned there (and nor is it's parent object(s)) it simply isn't relevant.  

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 tomorrow later in the day and send it to wildonrio for the test. Too early in the morning for me to do it now.  

[run088]

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.

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.

[Bomb Bloke]

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.

[Milleman]

Hi guys,

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

[Milleman]

I wonder if the FATX structured in the same way as the FAT32...

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?