So a friend let me borrow his super smash bros cart and rip it. I was gonna use it instead of the public one I have now but for some reason it's not working. All i did was rip it and change the extension to .3dz. What am I doing wrong?
Hacking Fragmentation Errors?
- Thread starter XDark_FenixX
- Start date
- Views 4,021
- Replies 22
- Joined
- Jul 7, 2010
- Messages
- 3,882
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 5,376
- Country
If you are getting a Fragmentation Error, read below, if not, disregard all
Means your microSD card is fragmented. You need to copy it w/o fragmenting.
Copy your rooms to the computer, format the MicroSD
Then go to the folder you put the roms into. Hold Shift + Right click -> Open Command Window Here
then type: for %i in (*) do copy "%i" X:
X: is your microSD
Remember to be a folder just with the roms, it will copy everything in the folder to your microSD
Means your microSD card is fragmented. You need to copy it w/o fragmenting.
Copy your rooms to the computer, format the MicroSD
Then go to the folder you put the roms into. Hold Shift + Right click -> Open Command Window Here
then type: for %i in (*) do copy "%i" X:
X: is your microSD
Remember to be a folder just with the roms, it will copy everything in the folder to your microSD
yes
hmmm... Here's the thing though: everything else works. Including my super smash bros w/ NSMB2 header. That took a bit of fiddling to work the first time so maybe its a smash thing?
Not really, this happens when you copy something over after deleting something to make space.
Don't quote me on this, but it basically means that the file isn't in a single 'block' of data. Like it's split in two or more pieces of data instead. It's way better to copy everything over with a format, instead of defragmenting your microSD, because they have limited number of 'writes' on it.
Like an SSD, this worries me.
- Joined
- Jul 7, 2010
- Messages
- 3,882
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 5,376
- Country
If you want to get nitty gritty with it, learn how the FS works (fat32 or exfat) and hex edit your files into the drive.
when you copy games, then copy them 1 at a time, if you use windows copy function
if you copy multiple at once, then it fragments the shit out of them - good job, windows *thumbs up*
or use a designated copy tool like TeraCopy, never had a fragmentation error with this tool (can copy as many games as you want at the same time)
also ... you know, you can just defragment the sd card
and when you format the sd card, for christ's sake don't use the windows tool for that, actually, never ever use any windows tool for anything, I have no idea, why people get paid to write those things, they are shit... use a designated sd formatting tool like for example "panasonic sd card formatter"
if you copy multiple at once, then it fragments the shit out of them - good job, windows *thumbs up*
or use a designated copy tool like TeraCopy, never had a fragmentation error with this tool (can copy as many games as you want at the same time)
also ... you know, you can just defragment the sd card
and when you format the sd card, for christ's sake don't use the windows tool for that, actually, never ever use any windows tool for anything, I have no idea, why people get paid to write those things, they are shit... use a designated sd formatting tool like for example "panasonic sd card formatter"
I always use windows format when I want exfat. Works great, Never had an issue.
That panasonic SD formatter is kinda retarded... never solved nothing for me.
That panasonic SD formatter is kinda retarded... never solved nothing for me.
if it never solved anything, then your issue just wasn't related to anything, it could solve
doesn't mean, that it doesn't work as it is intended to, though
Really never noticed any difference in performance or stability.
That dumb website gives no details about the software's inner working... it pretty much says "our software is magic".
People seem to forget it uses the same generic file system functions from generic card reader drivers any other format software must use.
It can't do anything better than windows because it's tied to the same rules.
Placebo 4 life.
you may think that, but 3rd party tools actually sometimes are just better than the windows solution
for example Defraggler is better than windows defrag, because it includes features, that the windows solution doesn't, like per file defragmentation and not only whole hdd defragmentation, also it works faster and in my experience more efficient than the windows solution
or take windows native copy function, copy 10 roms at the same time with it to your microSD and while everything MAY work, it might also result in a couple of them not working, because it randomly in its incompetence fragmented the files, TeraCopy for example sctrictly copies them 1 by 1 without fragmentation, even if you give it a list of 30 files to copy and even includes to possibility to do a crc check after the process
and in my experience 3rd party sd format tools sometimes help resolving issues, that come up with the windows format, I am not saying you HAVE to use panasonic sd formatter, it is just the first name that comes to my mind, when I talk about SD card formatting, there are a few other competent tools, too
and I'm basically just listing those options in case, somebody has an issue, he can't seem to resolve and then maybe one of these tools can help
You can fix GW3DS fragmentation errors with Gateway 3DS microSD Tool.
Everything else works because everything else is not fragmented.
You don't have to follow those complicated instructions though. Just copy all your roms out of the SD, format it (you can just use windows for this; make sure to uncheck "quick format", it'll take a while but it'll be thorough), and copy them back in.
This is correct.
There's absolutely no reason to uncheck 'quick fomat'.
It will just take much longer to format. There's no real benefit in zeroing the whole the card.
Pick exFAT and quick format and it's ready in a second.
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.
I believe they do something similar with the emuNAND mapping, it would be the only reasonable explanation as to why they store it on non-partitioned space instead of inside a file: once the space has been allocated, it is untouchable and impossible to fragment by moving files on and off the card by virtue of its separation. The drawback is that when your data is fragmented, you need to make exceptions from the mapping.
This is probably why Gateway apparently employs not one, but a list of offsets for ROMs, since fragmentation can't all be avoided. If the list is small, it will still be faster than having to do a fseek() everytime you want to find out where your data is, but as the fragmentation grows the list becomes either too slow or takes up too much memory(it shouldn't since it's just a list of addreses, likely less than 100 bytes). They set the threshold at 32 fragments, after which the ROM is considered too fragmented to load and an error pops up.
A larger cluster size reduces these chances since the amount of committed block of contiguous data becomes smaller but this in no way avoids instances where you delete a ROM and then copy a larger one in its place, causing it to become fragmented between the empty space left by the previous and the space beyond already written data.
To make sure no ROM ever gets too fragmented, the cluster size would have to be largest ROM size divided by 32, which is to say 4GB(don't think there are larger ROMs?) / 32 = 128MB cluster size, guaranteeing that even the largest ROMs are made of no more than 32 fragments at worst.
ExFAT can provide a whopping 32MB cluster size. This means that, in the worst possible scenario, any one ROM will be 4x more fragmented than Gateway can handle. But that's a lot better than the potentially thousands of scattered fragments that can happen. It also makes it impossible to overfragment ROMs of 1GB or less!
It has one downside: any amount of data written into a new cluster always occupies all of it, meaning that a 64.001MB file will occupy 96MB and so on. But while this may be a nightmare on a... say OS drive with thousands of tiny files on it, it's no biggie on an SD card with 10-20 files on it. Also, ROMs come in 2^n sizes and are all divisible by 32MB, so unless you're trimming your ROMs you won't be losing any extra space, and even then you still won't lose that much since trimming usually takes away a few hundreds of megs.
You also lose 32-64MB depending on the size of your last cluster + 2nd last cluster, which are also unusable by Gateway. But at this point even the dreaded defrag could become a viable option since it would have to move around only around 2000-8000 fragments instead of a few million, causing much less wear.
I haven't yet tried to format my microSD with ExFAT 32MB cluster size to know if Gateway can support it, but if it can, it could drastically reduce the number of fragmentation errors from drag-n-drop mundane copy and delete operations.
I believe they do something similar with the emuNAND mapping, it would be the only reasonable explanation as to why they store it on non-partitioned space instead of inside a file: once the space has been allocated, it is untouchable and impossible to fragment by moving files on and off the card by virtue of its separation. The drawback is that when your data is fragmented, you need to make exceptions from the mapping.
This is probably why Gateway apparently employs not one, but a list of offsets for ROMs, since fragmentation can't all be avoided. If the list is small, it will still be faster than having to do a fseek() everytime you want to find out where your data is, but as the fragmentation grows the list becomes either too slow or takes up too much memory(it shouldn't since it's just a list of addreses, likely less than 100 bytes). They set the threshold at 32 fragments, after which the ROM is considered too fragmented to load and an error pops up.
A larger cluster size reduces these chances since the amount of committed block of contiguous data becomes smaller but this in no way avoids instances where you delete a ROM and then copy a larger one in its place, causing it to become fragmented between the empty space left by the previous and the space beyond already written data.
To make sure no ROM ever gets too fragmented, the cluster size would have to be largest ROM size divided by 32, which is to say 4GB(don't think there are larger ROMs?) / 32 = 128MB cluster size, guaranteeing that even the largest ROMs are made of no more than 32 fragments at worst.
ExFAT can provide a whopping 32MB cluster size. This means that, in the worst possible scenario, any one ROM will be 4x more fragmented than Gateway can handle. But that's a lot better than the potentially thousands of scattered fragments that can happen. It also makes it impossible to overfragment ROMs of 1GB or less!
It has one downside: any amount of data written into a new cluster always occupies all of it, meaning that a 64.001MB file will occupy 96MB and so on. But while this may be a nightmare on a... say OS drive with thousands of tiny files on it, it's no biggie on an SD card with 10-20 files on it. Also, ROMs come in 2^n sizes and are all divisible by 32MB, so unless you're trimming your ROMs you won't be losing any extra space, and even then you still won't lose that much since trimming usually takes away a few hundreds of megs.
You also lose 32-64MB depending on the size of your last cluster + 2nd last cluster, which are also unusable by Gateway. But at this point even the dreaded defrag could become a viable option since it would have to move around only around 2000-8000 fragments instead of a few million, causing much less wear.
I haven't yet tried to format my microSD with ExFAT 32MB cluster size to know if Gateway can support it, but if it can, it could drastically reduce the number of fragmentation errors from drag-n-drop mundane copy and delete operations.
I was under the impression that picking quick format (and thus actually leaving all the data there) could lead to fragmentation instantly upon copying some files into the device, probably as a result of how shitty Windows is. I seem to remember this happening to me once, but I'm not 100% sure.
i downloaded ssb 3dz from the requisite iso site , and i copied it to my sd after deleting a couple other roms put it in my GW and i got fragmentation error, took it out put it back in my PC deleted ssb.3dz and recopied it and it works fine now
nope a quick format just marks everywhere as unallocated.....so just the same as a full format in terms of the possibility of fragmented files, but it just doesn't physically zero the drive
Flash memory has a limited number of writes, formatting just uses up one of it's lives. It's only real use is trying to prevent someone from seeing what you had on there before.
If you paste multiple times then it will fragment them because it's doing what you asked. You can copy multiple files using a single copy/paste or a command line just fine.
Windows isn't retarded because it doesn't queue them up, although I agree it would be a nice feature to have.
