Hacking FAT32 instead of WBFS

[ideal2545]

I dont understand why we are not able to use FAT32 for our ISO backups. This would make life easier in the sense that we could load our games, movies, and music onto the same harddrive. I understand that NTFS is closed source... but FAT32 is not. Does anyone know why WBFS was developed and being used instead?

 

[chicou]

Hi,

You cannot have a file bigger than 4gig in fat32.

I know for the majority of ISO are not bigger than 4gig but a 4gig files will not be able to be created.

This is what I though about this.

Chicou

 

[FenrirWolf]

First, ISO's bigger than 4GB would have to be split to work in FAT32. Second, games in WBFS are able to be reduced to their scrubbed size, while in FAT32 they'd be full sized regardless of if they're scrubbed. Third, WBFS is made so that file fragmentation is pretty much nonexistent, allowing the game file to be read without having to jump around and look for bits and pieces.

Also, you CAN load your games, movies, and music onto the same HDD. Have your first partition be in FAT32 and the second in WBFS.

 

[Athlon-pv]

WBFS is far superior to fat32 for this kind of thing, there have been posts about the technicle details.

To be short dont expect anything like fat32 for usb loader.

 

[Amarabha]

That is one point.

And I think it has something to do with the point, that the ISO's when coppied to the WBFS Drive actually do have a smaller size, because (this is what i believe, i didn't check that) only the needed data is transfered, not the crap to blow the size up to 4.37gb. I think this a special copy protection mechanism, and booting the ISO won't work with FAT32 FS...

Amarabha

 

[WiiPower]

First, ISO's bigger than 4GB would have to be split to work in FAT32. Second, games in WBFS are able to be reduced to their scrubbed size, while in FAT32 they'd be full sized regardless of if they're scrubbed. Third, WBFS is made so that file fragmentation is pretty much nonexistent, allowing the game file to be read without having to jump around and look for bits and pieces.

Also, you CAN load your games, movies, and music onto the same HDD. Have your first partition be in FAT32 and the second in WBFS.

It's not a file splitting (for Waninkoko 10 minutes work),scrubbing or fragmentation problem. The problem is how to implement FAT drivers in the IOS. The storage access from the dip module uses the arm processor instead of the ppc processor. And when writing homebrew you can easily use the FAT drivers from libogc, which you can't for the IOS.

 

[manias]

geez use partitions

 

[FenrirWolf]

Ah, I see. Thanks for clarifying.

 

[sorgelig]

The problem is how to implement FAT drivers in the IOS. The storage access from the dip module uses the arm processor instead of the ppc processor. And when writing homebrew you can easily use the FAT drivers from libogc, which you can't for the IOS.

FAT is implemented in libfat, not libogc. But anyway, both are available in source code. Keep in mind that IOS uses HDD for read only, so FAT support code can be greately reduced.
I could try to integrate FAT support, but there is no full source code published for cIOS rev 9/10.
I don't see any REAL disadvantages of FAT32. It's not a problem to split ISO, it's not a problem to create simple compression for scrubbed ISOs to occupy less space on storage. There is REAL advantage of FAT - ability to access from almost any OS.

 

[WiiPower]

The problem is how to implement FAT drivers in the IOS. The storage access from the dip module uses the arm processor instead of the ppc processor. And when writing homebrew you can easily use the FAT drivers from libogc, which you can't for the IOS.

FAT is implemented in libfat, not libogc. But anyway, both are available in source code. Keep in mind that IOS uses HDD for read only, so FAT support code can be greately reduced.
I could try to integrate FAT support, but there is no full source code published for cIOS rev 9/10.
I don't see any REAL disadvantages of FAT32. It's not a problem to split ISO, it's not a problem to create simple compression for scrubbed ISOs to occupy less space on storage. There is REAL advantage of FAT - ability to access from almost any OS.

The source for the FAT drivers is available, i know. But it's ppc code, that calls functions of the IOS, i thought that's a little complicated to change that to arm code and that does everything that ppc+arm do for homebrew FAT access. It might be easier to use the FAT drivers from mini, but that does not run in an IOS, so a lot of stuff is done in a different way i guess.

 

[rizlas]

ntfs support could be added acording to marcan @ Hackmii
whether it is or not is a different story

 

[sorgelig]

The source for the FAT drivers is available, i know. But it's ppc code, that calls functions of the IOS, i thought that's a little complicated to change that to arm code and that does everything that ppc+arm do for homebrew FAT access. It might be easier to use the FAT drivers from mini, but that does not run in an IOS, so a lot of stuff is done in a different way i guess.

as long as source code doesn't include assembler code, it can be compiled as any CPU code. Abstraction (from hardware) level used by WBFS is the same as for FAT.
So, basically, WBFS source code can be changed to FAT or even (better) to NTFS.

 

[sorgelig]

by the way. NTFS could be really helpful because it supports compression on the fly. In other words, we don't need to care about space for scubbed ISOs. These ISOs will occupy as less space as on WBFS (or even less). So, we will able use ISO without any additional modifications.
I'm only not sure if linux source code for NTFS supports compression or not.
Also, no need to care about decompression speed. It surely will be higher than reading DVD from drive.

As i stated before, IOS requires only reading. So, support code can be reduced.

 

[cwstjdenobs]

by the way. NTFS could be really helpful because it supports compression on the fly. In other words, we don't need to care about space for scubbed ISOs. These ISOs will occupy as less space as on WBFS (or even less). So, we will able use ISO without any additional modifications.
I'm only not sure if linux source code for NTFS supports compression or not.
Also, no need to care about decompression speed. It surely will be higher than reading DVD from drive.

As i stated before, IOS requires only reading. So, support code can be reduced.

NTFS is ancient, inefficient, has high overheads, is prone to fragmentation, and has lowsey compression. Plus on the fly compression would grind starlet to a halt.

 

[WiiPower]

by the way. NTFS could be really helpful because it supports compression on the fly. In other words, we don't need to care about space for scubbed ISOs. These ISOs will occupy as less space as on WBFS (or even less). So, we will able use ISO without any additional modifications.
I'm only not sure if linux source code for NTFS supports compression or not.
Also, no need to care about decompression speed. It surely will be higher than reading DVD from drive.

As i stated before, IOS requires only reading. So, support code can be reduced.

If NTFS would ever be added then without the compression. Enable compression on something with less than 2 GHz and you will know what i mean.