That would be a great way to get coding practice, but is it really a necessary program? Is WBFS fragmentation an issue that hits performance? I haven't heard of any cases of that myself.

And beyond that, how many people would have a use for it? With FAT32 loading and all the conveniences it brings, it shocks me people still format their drives as WBFS.

 

I'm amazed that there are already 2 people willing to put their entire game collection at risk to test a tool for an obsolete partitioning system.


It's not my intention to bash WBFS, but come on...it's been nearly two years since FAT32 became possible, and all that time I heard nothing but bogus arguments in favor of WBFS. The reason it's still being used is because 1. the interweb has quite some outdated guides floating around and 2. because people don't want to change from whatever works.

"2." will be a culprit. Your beta testers (or even end users) will obviously need a backup of their backups*, and if they go through that trouble...why not just reformat it to FAT32 and use Wii Backup Manager to convert the games? Since it'll be a blank disk, it'll be completely defragged in the end!


So...yeah. I appreciate coding projects, and it IS something new. I just hope a program like this won't make people think WBFS can even be considered "equal" to FAT32.







*you gotta love how the word "backup" is used on gbatemp

 

Do you know, that some FAT/NTFS defragmentation tools calculates a fragmentation ration in fragments per MiB. Most of them say, that a ratio of =2 MiB (a 350 GB drive has chunks with 8 MiB). That means, that the ratio can never be larger than 0.5. And in the terms of above, a WBFS is never fragmented.

This is the theory, and here are some tests:
A year ago I have created 2 WBFS, one absolutely defragmented (1 disc behind the other) and one where every disc has many fragments (I think it was with 16 MiB fragments). Then I have made 2 tests:
a.) reading the data in line and randomly with an PC.
b.) playing some games (e.g. "Sims 3" do much loading in every scene change)
I have found only minimal differences for case a), but not for case b).

Will say: It is not worth it!


BTW:
It make more sense, to have an more intelligent block selection algorithm adding a new disc to a WBFS. I have already implemented one (together with some other new WBFS stuff) in wwt for a long time, but not activated, because it is not tested very well. I have stopped this development + testing, because of the tests and results above. You can enable it, if compiling my tools with "make new all".


The poll:
I have answered, that I don't need the tool, but I will test it. Linux+cli are welcome and I will never test a windows-click-solution. Full automated scripts are the best!

Why should he making WBFS worse to be equal to FAT?

 

When I unplug my wbfs drive while writing a wbfs using my wit tool, nothing happens, because the complete WBFS management data is hold in memory and only written, if adding the disc is finished. The only critical moment is while writing this management block. I have rewritten the LIBWBFS for this secure handling.
Oh, this is better than FAT handling!

My tools are very fast, because of writing the game data in linear order and storing the management data last. FAT(NTFS management data is to large and for block allocations, some non linear read+write operations are needed.
Oh, this is better and faster than FAT handling!

Before writing to a WBFS, my tools do a *complete* integrity check and repair small errors without user confirmation. This takes not a second and most users don't see it. Only for harder errors the program exits without writing.
Oh, this is better and much faster than FAT handling!

There are no fragmentation problems because of the very large chunks.
Oh, this is better than FAT handling!

All thinks above work only, because the management data of a WBFS is very small. FAT and NTFS can't do such optimized things.

And now please tell me again the technical advantage of a FAT system. The only I know is, that it is easier to copy/rename files if using mouse control. But this little advantage is blown if using cli.


I'm a WBFS fan. I have switched to FAT, saw all disadvantages, and switched back to WBFS.

 

For clearness:
All USB loader use *always* WBFS, either directly or as WBFS file in a FAT/NTFS file system. Therefor using FAT/NTFS adds only a new layer of file access. I think the WBFS support stays forever.
(btw: ULoader supports CISO, an alternative container for WBFS).

I think, everyone can make it's own decision which variant he/she use. But I don't like, if so many people without knowledge about WBFS say, that WBFS useless/old/bad/faulty. I see clear advantages for me and so I'm stay on it.

 

The only reason you can use 4gb+ games on FAT32 is because the file gets splitted. So its not really a 4gb+ file anymore.


For pure Wii use, WBFS has a lot of advantages, but the compability of FAT32 across different platforms is hard to ignore.
Therefore Im using FAT32 and will most likely stick to it untill the Wii ends up in a closet lol.

 

That's a main problem here. I know, that for most people FAT/NTFS management is much easier than WBFS. But the arguments are most wrong, because the most people here doesn't know, what WBFS is from a technical view point. On the other hand, many WBFS people using the old and buggy "WBSF Manager 3.0" (and other old and buggy tools) and if the tool makes an error they say: "shit WBFS" and not "shit WBFS manager".

 

Because some older drives only work with WBFS. For game loading, compatibility is WBFS > FAT32 > NTFS

 

...because you know nothing about WBFS. No usb loader runs without WBFS. It open wbfs as device or as file on FAT/NTFS/ext*.

 

Works fine for me, I just know a couple people who can't run FAT32 (idk about NTFS) on their HDD, no matter what cIOS is used. It always works fine for WBFS though.