Hacking Fragmentation Errors?

[Searinox]

As an update to my previous post.

I believe that what Windows does - probably in order to speed up copy - is that when it begins copying a bunch of files, it will copy the files one by one BUT will opportunistically retrieve the first chunk of data it can grab. So say fragments 101 and 436 were one after another on the HDD as the platter spins, Windows would immediately fetch and write those to the microSD in that order, potentially carrying the fragmentation on to the new drive. I don't think it's copying random pieces of the pending files opportunistically because it seems to list them in order during the copy process, but I very much believe it does it with the specific file being currently copied.

I formatted the microSD to 32MB cluster. I have all my ROMs trimmed except the Pokemon games... I lost about 300MB in the process. I then - ASSUMING Windows creates files in the nearest available cluster, in order from first to last cluster - copied a few thousand 1-byte files til the card was full. I renamed and locked the last 2 as read-only, to make sure I'm keeping the last 2 clusters occupied and no ROM data accidentally gets there, and deleted the rest of the files I made in the process.

ROMs seem to load a bit faster. I've always had ONE ROM with fragmentation error even on a fresh format drag-n-drop copy of all the ROMs, and this time there were none. Note that this does NOT qualify as a definite answer since it was just ONE test on my side with my Windows and my setup. But I can say... it's at least possible. For any others interested in trying. Note that while ROMs load faster from Gateway's menu, it's a 0.5s to 0.25s difference, so pretty small, and ROMs do NOT boot up any faster.

Also remember that I lost 300MB thus far with my trimmed ROMs vs. perhaps a few KB on default cluster size. This is with 16GB worth of ROMs on a 32GB card. By the time I fill up the partition, I'll probably have lost a total of around 500MB(not 600 since cards - and just about anything out there - only has about 90% of claimed capacity). That's enough for a small ROM.

 

[_Tim_]

The Gateway must be using some sort of simplistic mapping that just sets the offset of the first cluster of the ROM as the first readable byte. The whole rest of the read requests then assume the data should be found at the offset + address location. This assumption requires the ROMs to be contiguous, that is one big, continuous chunk of data from start to finish on the partition. It was either done out of simplicity of coding or need for speed.

GW3DS 2.3 (the last version I checked) can handle rom files with up to 32 fragments just fine. 95% of the reported fragmentation errors are caused by the dreaded GW3DS exFAT bug. If a rom file uses either of the last two clusters on an exFAT filesystem... fragmentation error. The tool I linked to a few posts up can fix this issue in a matter of seconds and "inoculate" the microSD card against this bug. I've only seen 1 or 2 persons who actually managed to have rom files with more than 32 fragments.

 

[Searinox]

GW3DS 2.3 (the last version I checked) can handle rom files with up to 32 fragments just fine. 95% of the reported fragmentation errors are caused by the dreaded GW3DS exFAT bug. If a rom file uses either of the last two clusters on an exFAT filesystem... fragmentation error. The tool I linked to a few posts up can fix this issue in a matter of seconds and "inoculate" the microSD card against this bug. I've only seen 1 or 2 persons who actually managed to have rom files with more than 32 fragments.

As I said in the post, I managed to create two files and placed them on the last 2 clusters of the microSD. They should keep the data locked there. But since we're here... are there any tools to arbitrarily move clusters around? Like say take cluster 31 and move it to cluster 4052.