Print

[ldotsfan]

I have started to migrate all LBA variables to ULONGLONG or 64 bit integers except when storing the partition table to hdd, discard the upper 32 bits.

Hopefully this approach will resolve the earlier issues of overflowing when large size hdds 1TB and beyond are used.

[ldotsfan]

Code is done.

[shambles1980]

have you compiled this and added it to xbins?

could be usefull.

[ldotsfan]

1. Compiled XBE - Yes.
2. Testing - No.
3. Xbins - No. No access.

[ldotsfan]

I did some basic testing with a small hdd but without the necessary equipment (1-2TB hdd and matching sata/pata adapter), I cannot test the desired functionality.

[shambles1980]

i may be able to help
i have a 1.5 tb drive and a sata adapter but i havent confirmed the sata adapter is compliant with the xbox. it's in a mame project.

i will have to transfer files from the 1.5tb drive to other drives on my system before i can do any testing.

but send me a pm and il see what i can do about moving files tonight and a should be able to do some testing tomorrow.

[mike26]

I have modded a ton of 2tb drives and would love to use this and test this. Is there anyway to get ahold of it? I am trying to format the G drive of my 2tb sata drives to allocate 1.7TB and leave the F drive formatted 120gb 16kb Clusters so xmugen and linux play nice.

[ldotsfan]

I've made a minor but important change to xbpartitioner 1.1 code. It reads the cluster size from the FATX superblock of the extended partitions and displays it on-screen. When formatting 32K and 64K clustered large partitions, this will confirm the actual cluster size used since the value is read from the hdd AFTER the formatting has been completed. I've only managed to test 16K and 32K by rotating among the existing supported partition schemes for F and G, ie F takes all, F and G splits equally and so on. 64K is untested since I don't have a hdd of that size.

I will only release the relevant changes in patch to the source code and not the binary for obvious reasons. I added one method and modified another method. And modified one struct.

Will attach the code in another post.
   







partition.h

CODE

typedef struct _FATX_SUPERBLOCK
{
    char    Tag[4];
    unsigned int        VolumeID;
    unsigned int    ClusterSize;
    USHORT    FatCopies;
    int        Resvd;
    char    Unused[4078];
} FATX_SUPERBLOCK;

PartInfo.cpp

CODE

wchar_t buf1[200], buf2[200], buf3[200], buf4[200],buf5[200];

unsigned int
get_clustersize(ANSI_STRING part)
{
    HANDLE hDisk;
    NTSTATUS status;
    OBJECT_ATTRIBUTES ObjectAttributes;
    IO_STATUS_BLOCK IoStatusBlock;
    BYTE PartSector[XBOX_HD_SECTOR_SIZE*8];
    LARGE_INTEGER RWOffset;
    FATX_SUPERBLOCK fsb;

    InitializeObjectAttributes(&ObjectAttributes, &part, OBJ_CASE_INSENSITIVE, NULL);

    RWOffset.QuadPart = 0;
    memset(PartSector, 0, sizeof(PartSector));
    
    status = NtOpenFile(&hDisk, SYNCHRONIZE | GENERIC_ALL, &ObjectAttributes, &IoStatusBlock, 0, FILE_SYNCHRONOUS_IO_ALERT);
    if (NT_SUCCESS(status))
        status = NtReadFile(hDisk, NULL, NULL, NULL, &IoStatusBlock, (PVOID) PartSector, sizeof(PartSector), &RWOffset);
    else
        return 0;
    NtClose(hDisk);
    memcpy (&fsb,PartSector,sizeof(PartSector));
    return fsb.ClusterSize/2;

}

void DrawTable(XboxPartitionTable *PartTbl, ULONG TotalSectors, int g_iCurrentPart)
{
    ULONG FreeSectors = part_get_free_sectors(PartTbl, TotalSectors);
    int i, offset = 8;
    unsigned int cluster_size;

    LARGE_INTEGER sz, free_sz;
    sz.QuadPart = (ULONGLONG) TotalSectors * 512UL;
    sz.QuadPart /= 1048576;
    free_sz.QuadPart = (ULONGLONG) FreeSectors * 512UL;
    free_sz.QuadPart /= 1048576;
//    swprintf(buf1, L"Disk Size: %I64uMB - %I64uMB Free", sz, free_sz);//((ULONGLONG) TotalSectors * 512UL)) / 1000000000000UL;
//    DisplayText(buf1, 50, 20 * g_ypos++, 2);

    g_ypos = 4;
    for (i = 0; i < 5; i++)
    {
        swprintf(buf1, L"%d", i+1);
        swprintf(buf2, L"start %.08x", PartTbl->TableEntries.LBAStart);
        swprintf(buf3, L" size %.08x", PartTbl->TableEntries.LBASize);
        swprintf(buf4, L"%.2f MB", (double) ((ULONGLONG) PartTbl->TableEntries.LBASize * 512) / 1048576);


        if (g_iCurrentPart == i /*&& PartTbl->TableEntries.Flags*/)
        {
            DrawRect(48, (float) (20 * g_ypos + offset - 4), 596, (float) (20 * g_ypos + offset + 20), 0xa0404040, 0xa0000000);
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 4 : ;
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 0 : 4) : (g_iMovePart ? 0 : );
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 4 : 0) : (g_iMovePart ? 8 : 0));
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8, XFONT_RIGHT);
        }
        else
        {
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7, XFONT_RIGHT);
        }
    }

    g_ypos += 2;

    offset = 13;


    for (; i < 14; i++)
    {
        swprintf(buf1, L"%d", i+1);
        swprintf(buf2, L"start %.08x", PartTbl->TableEntries.LBAStart);
        swprintf(buf3, L" size %.08x", PartTbl->TableEntries.LBASize);
        swprintf(buf4, L"%.2f GB", (double) ((ULONGLONG) PartTbl->TableEntries.LBASize * 512) / 1073741824);
        cluster_size = get_clustersize(partition_str);
                        if (cluster_size !=0)
                        {
                            swprintf(buf5, L"%dK", cluster_size);
                        }
                        else
                        {
                            swprintf(buf5, L"");
                        }

        if (g_iCurrentPart == i /*&& PartTbl->TableEntries.Flags*/)
        {
            DrawRect(48, (float) (20 * g_ypos + offset - 4), 596, (float) (20 * g_ypos + offset + 20), 0xa0404040, 0xa0000000);
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 4 : ;
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 0 : 4) : (g_iMovePart ? 0 : );
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? (g_iMovePart ? 4 : 0) : (g_iMovePart ? 8 : 0));
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 4 : 8, XFONT_RIGHT);
        }
        else
        {
            DisplayTableText(buf1, 50, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf2, 84, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf3, 258, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
             if(cluster_size!=0 && PartTbl->TableEntries.LBASize>0)
                DisplayTableText(buf5, 438, 20 * g_ypos + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7);
            DisplayTableText(buf4, 592, 20 * g_ypos++ + offset, (PartTbl->TableEntries.Flags & PE_PARTFLAGS_IN_USE) ? 2 : 7, XFONT_RIGHT);
        }
    }
}

[Bomb Bloke]

Ooh, handy! Indeed, many users get confused and think XBP is already informing them of the current cluster size. I tried to avoid that with the wording used in 1.1, though I don't think I was very successful.

There's also that silly crash bug when XBP sees a partition larger then 1tb. This is due to the "compare" variable in "PartInfo.cpp" being set to a ULONG - it's used to calculate the correct cluster size when formatting a partition, but overflows if used to check one of 1tb or larger. Quick fix is to just set it to a ULONGLONG or something. Note that it's dimensioned in two different places in the file, so both need to be tweaked. Same file also contains the the text telling the user what version of XBP they're running, in case you missed it; just do a search for "1.1" and you'll find it easy enough.

1tb partitions don't work anyway (no dash will read the resulting partition - dunno if this is a dash fault or a formatting fault), but the whole "crash-forcing-the-user-to-go-back-to-1.0" situation is hardly elegant either. I'd considered just enforcing a hard cap to partition sizes instead - even have a version that does that somewhere on my drive - but couldn't make up my mind as to whether this would simply make it harder for people to maybe later get 128kb clusters working. Didn't release either version as 1.2 as I wanted to make some more changes first, but was too lazy.

One idea I had on the table was to have XBP throw up a visual warning directly prior to formatting, noting that unchanged partitions would be left alone. Changing the behaviour so that it formatted partitions regardless of whether they were altered or not would be somewhat risky, as if a user got confused and asked XBP to format all partitions, it'd actually do it. As opposed to the current system, where it should only format the partitions that have had a new size set - which is admittedly not an intuitive one, but would be just fine if the users were properly warned.

Another was to make it so that the analog sticks could be used on the "help" page to re-calibrate the image on the TV screen.

All just some of the many projects I come up with then never do. A third was to have XBMC check the cluster sizes on all available partitions during its startup process. If it found any to be incorrect, it'd put up a visual prompt warning the user of the danger, and perhaps pointing them at a URL for a full document explaining what to do about it. Given that most people run XBMC a tad more often then they do XBPartitioner, this'd probably filter out many bad partitions before the users actually encountered data loss.

This post has been edited by Bomb Bloke: Jun 16 2010, 11:29 AM

[Heimdall]

Great work ldotsfan.  

QUOTE(Bomb Bloke @ Jun 16 2010, 11:22 AM)

Another was to make it so that the analog sticks could be used on the "help" page to re-calibrate the image on the TV screen.

All just some of the many projects I come up with then never do. A third was to have XBMC check the cluster sizes on all available partitions during its startup process. If it found any to be incorrect, it'd put up a visual prompt warning the user of the danger, and perhaps pointing them at a URL for a full document explaining what to do about it. Given that most people run XBMC a tad more often then they do XBPartitioner, this'd probably filter out many bad partitions before the users actually encountered data loss.

These are excellent ideas. I had a quick look at the first one, thinking I could lift the screen resizing code from XBMC and reuse it, but it's way beyond my current programming abilities. (If I'm honest, I couldn't even find the code in XBMC to copy!!) Taking the cluster size checking code into XBMC is an even better idea.

Who says the Xbox 1 is dead?

[ldotsfan]

Pictures:
16K clusters:


32K clusters:
2.

A 256GB partition wrongly partitioned. I commented out some code to create an always 16K xbpartitioner in order to test this prior to this
3.

1. 128K may not be necessary now that we have multiple extended partition support in XBMC  
2. Made the change to the version title.
3. Calibration screen will require major GUI redesign. An easier way will be to incorporate a subset of the partitioning capability into XBMC2XBOX which is after all a dash. I have some ideas on the feasibility and will explore further.
4. The ERR message is indicative of a partition formatted with the wrong cluster size for the partition size.
5. I've implemented Bomb Bloke's suggestion on the hard cap to partition sizes. IMHO, 1TB overflows not just for compare variable but my experience with xboxhdm3 tells me that the journey to 1TB and 128K clusters is a rough ride and there are many issues yet to be resolved, including a rewrite of oz_paul's partitioning code in the bios which is way beyond my ability. Hence I err on the safe side.
6. I have some ideas on how to incorporate the warning cluster size into XBMC. Log a warning into XBMC log file and treat the partition like an invalid remote path. Will explore further.

[Bomb Bloke]

All sounds good.

If you define a partition but haven't yet formatted it, will it report ERR, or nothing at all?

Indeed, odds are no one will ever have a need to use 128kb clusters. Some people may want to put all their space on F, but really they'd just be throwing all their capacity into slack space.

A check-list for the cap: It needs to be enforced when "assuming" the partition layout for an unformatted drive during startup, when the user cycles through pre-set space layouts, and when the user manually attempts to alter the partition sizes. To memory I just threw something into the main program loop to see if each partition was in range, and lower the set size if not.

[lordvader129]

QUOTE(Bomb Bloke @ Jun 17 2010, 01:15 AM)

Indeed, odds are no one will ever have a need to use 128kb clusters. Some people may want to put all their space on F, but really they'd just be throwing all their capacity into slack space.

not necessarily, it would depend on how many/what kind of files they have

if its mostly xbox games, then yes, youll lose a significant amount to space due to slack on the hundreds of thousands of small files, but if they are keeping large files like movies or tv shows they slack difference may only be a few megabytes, which would be an acceptable trade for not having free space split between 2 partitions

its obviously not a priority, but not something id take of the todo list just yet either

one downside would be if XBMC would be made to handle 128k clusters i think it will be the only dash able to do so, so the F: partition wont work in any other dash (no loss if your like me and just use the xbox for movies)

also, i wonder if 128k clusters would have any issue with running games, would that be a bios thing?

[ldotsfan]

QUOTE(Bomb Bloke @ Jun 17 2010, 04:15 PM)

If you define a partition but haven't yet formatted it, will it report ERR, or nothing at all?

Nothing.

QUOTE(Bomb Bloke @ Jun 17 2010, 04:15 PM)

A check-list for the cap: It needs to be enforced when "assuming" the partition layout for an unformatted drive during startup, when the user cycles through pre-set space layouts, and when the user manually attempts to alter the partition sizes. To memory I just threw something into the main program loop to see if each partition was in range, and lower the set size if not.

It is done at the point of addition to partition size at the backend and not the GUI for my implementation.

Code:
1. PartInfo.cpp
2. partition.cpp
3. partition.h
4. XBMC patch. This will hide a corrupt FATX partition with the wrong cluster size and log a warning to XBMC log. It builds on the earlier multiple extended partition patch for XBMC.

[ldotsfan]

The total sector count will overflow as well for a hdd sized over 1TB for 1.1.

I've made changes to the code to fix this. The capping of sizes wasn't done correctly earlier too.