Inside WBFS
A few truths about WBFS

While I'm working with my WBFS tool (WWT) I take some deeper looks into the WBFS subsystem and found some interest things.

Overall in the internet you can read that the maximal number of discs is that a WBFS partition can contain is about 500. This is true but not the whole truth. The value depends of the sector size parameter. It defines the number of bytes of 1 hd sector. The first sector of a WBFS partition is reserved for the WBFS header (12 bytes) and for a disc table (all other bytes, 1 byte per disc).

The user/tool can set the sector size while formatting a WBFS partition. The default sector size is 512. WWT knows the option --sector-size and may format a WBFS partition with different sector sizes. This is nice for testing.

The following dump shows the specific parameters of a WBFS partition with about 2 tera bytes (a file with exact 2.000.000.000.000 bytes). WWT creates this as sparse file so that the WBFS partition only needs 16 KiB disc space after formatting:

Code:

DUMP of a.wbfs

WBFS-Header:
MAGIC:				  'WBFS' = 57 42 46 53
number of sectors:   279303400
hd sector size:			  9 ->		512
WBFS sector size:		   26 ->   67108864

hd:   sector size:		   512 = 2^9
hd:   num of sectors: 3906250000
hd:	total size:	   1907349 MiB

wii:  sector size:		 32768 = 2^15
wii:  num of sectors:   61035008
wii:  sectors/disc:	   286864
wii:   total size:	   1907344 MiB

wbfs: sector size:	  67108864 = 2^26
wbfs: num of sectors:	  29802
wbfs: sectors/disc:		  140
wbfs:  total size:	   1907328 MiB

partition lba:				 0
free blocks lba:		  131064
disc info size:			 1024

used disk space:			 640 MiB =   1%
free disk space:		 1906688 MiB =  99%
total disk space:		1907328 MiB = 100%

number of wii discs:		   0	 =   0%
max disc:					500
disc open:					 0

With sector size 512 the maximal number of discs is set to 500 (=512-12). But when a WBFS is formatted with sector size 2048 than it may contain up to 2036 (2048-12) discs. See the dump:

Code:

DUMP of a.wbfs

WBFS-Header:
MAGIC:				  'WBFS' = 57 42 46 53
number of sectors:  1143551290
hd sector size:			 11 ->	   2048
WBFS sector size:		   25 ->   33554432

hd:   sector size:		  2048 = 2^11
hd:   num of sectors:  976562500
hd:	total size:	   1907349 MiB

wii:  sector size:		 32768 = 2^15
wii:  num of sectors:   61034496
wii:  sectors/disc:	   286864
wii:   total size:	   1907328 MiB

wbfs: sector size:	  33554432 = 2^25
wbfs: num of sectors:	  59604
wbfs: sectors/disc:		  280
wbfs:  total size:	   1907328 MiB

partition lba:				 0
free blocks lba:		   16380
disc info size:			 2048

used disk space:			 640 MiB =   1%
free disk space:		 1906688 MiB =  99%
total disk space:		1907328 MiB = 100%

number of wii discs:		   0	 =   0%
max disc:				   2036
disc open:					 0

I don't know if other tools and the usb loaders support other sector sizes (this is subject of later tests, perhaps others will do that) but the solution is very easy: Read the WBFS sectors before calling the function wbfs_open_partition() and calculate the sector size:

CODEwbfs_head_t whead;
stat = ReadAt(file,0,&whead,sizeof(whead));
if (stat) { ERROR_HANDLING; }
sector_size = 1

 

This is exactly why all of this is so confusing..

HD Sector Size:
All hard disk drives have a specific sector size, it cannot be modified. For most (all?) drives it is 512.

WBFS Sector Size:
All WBFS Formatted drives (partitions) have a dynamically set WBFS sector size. This seems to be calculated by making sure that the WBFS sector count will fit into 16 bits.

What Wiimm is talking about is telling the libWBFS code that the hard drives sector size is larger than it actually is.

It seems that this might be a workaround for the max game count limit.

But there is a limitation to take note of, you can only read data from a drive in multiples of the real HD sector size.

Also notice that the WBFS sector size is doubled in his example above (I'm not sure what effects this might have, if any).

Interesting stuff, nonetheless.

=]

 

It seems the two of you have a pretty good grasp of WBFS, so I'll ask you both, would a tool to resize a WBFS partition be possible or not? Just wondering if it is at all possible...before I take the time to start poking around. Sorry if this strays a bit OT.

 

Finally a good read among the childish crap in other threads.

Thanks

 

There where very little infos about the specs in the header file anyway i think 500 Games are more as enough

 

I have tested sector-size = 2048 with USB loader cfg and Waninkokos USB load 1.5:
As expected, it does not work.

 

Fine!

I have used WWT to add+extract about 50 games in 2 series (sector size 1024 and 2048) without any errors. The extracted games are identically to the sources. And this means: WWT is your friend for creating and filling WBFS partitions with other sector sizes.

 

It's hard (for me) to learn the details of wbfs. There is nearly none inline or other documentation. And before checking or resizing a wbfs partition the author must know precisely the impact of each parameter.

 

If you have a disc with 4 or more partitions then the Wii will refuse to read it anyways - it's a problem I encountered when I did the multidisc.

However......

The standard code included in the libwfs does not handle the second partition table (or third and fourth) - this means the VC games on SSBB are not seen for example. There doesn't seem to be limits on those tables.

You also need the u64 as for a Wii disc the stored values need to be multiplied by 4 to get actual - taking you over the 32 bit limit.

 

The problems with resizing come down to the field labeled "WBFS_SECTOR_SIZE" up above (and it's companions)

When a partition is initialised it effectively splits the storage space down into 64k chunks - these chunks are where the data is stored in the WBFS partition and represent a cluster of data. Each chunk is the size of WBFS_SECTOR_SIZE and starts at location partition start + wbfs header + game header table + usage table + WBFS_SECTOR_SIZE * cluster_number.

If you look at the header for a game placed on a WBFS partition you'll see the usual game name etc. and then a cluster usage table of 16 bit values. This table is created by down-converting the Wii's 32k usage map.
i.e. if the Wii disc showed data at 0x40000 to 0x50000 and 0xf800000 to 0x10000000 then 38000000 to 390000000 the cluster table would allocate data from the disc pool to cover those areas. The size of the games cluster table is derived from the size of a Wii disc divided by the WBFS_SECTOR_SIZE. If you look at the WBFS disc data with a hex editor you'll likely see some random data after each games cluster table as the routines don't usually pad the table out to the disc sector size.

This has the overall effect of each cluster containing WBFS_SECTOR_SIZE bytes of Wii disc data even if the original disc usage table showed only 32k as used.

When you resize the partition, the value of WBFS_SECTOR_SIZE etc. will be altered and data will need to be moved on the disc so that the pointers inside the games are corrected.

The limit on clusters is still 64k but each games cluster table entries will now be based around the old sized cluster/sector size and so data will be read incorrectly.

It's a lot of tweaking of data required as you have to modify each games cluster usage table entries that are already on the disc as well as the overall usage table..

The easiest way to resize would seem to be keep two copies of the usage table in memory. One representing the old size and the second representing the new size and copy the complete partition from one copy to the other, one game at a time. This is of course ensuring you don't overlap data blocks during the copy and you maintain disk usage tables correctly etc.

It's a lot of work for minimal real benefit.