After venturing into retro gaming by way of an Anbernic RG35XX and a PowKiddy v90, I decided it was time to dust off my old Nintendo 3DS XL and get it a bit more battle ready to do some retro gaming. Part of the spring cleaning was to upgrade the memory card from the 32GB card I was using, to the 256GB card I had laying around that I originally had in my v90.
Worth noting, the 256GB card was just overkill in the v90, primarily due to how long it would take to scan the disk after a borked shutdown sequence. Moving to a 64GB card took the scan time down substantially, and still allowed for enough space for the stuff that the v90 was capable of playing.
All right, to to upgrade my 3DS’s SD card, I went ahead and backed it up, formatted the new card, and moved the files to it. Easy peasy.
Once I popped the card back in and booted up though, it was extremely slow to boot compared to the other memory card. After some researched, what I was experiencing was expected behavior for the 3DS when using a larger SD card. I guess it makes sense, the card is 8 times the size, and I guess the 3DS has to do some scanning or something.
Regardless of the slowdown, I’m happy with the decision to throw some more memory in there, and the delay is just a few seconds, and game launch from the SD card without any noticeable issues.
That said, I did do a bit more research and read that if you use a larger card, you have to make sure the card is formatted to 32kb per cluster, or things would be slow.
Well things were slow for me, so obviously my card wasn’t formatted correctly.
Before hastily reformatting the card and started over, I decided to figure out
how to tell what the card’s cluster size was set to. To do so, you need to use
dosfsck command with the following arguments:
-v- verbose output, otherwise you won’t get the cluster value
-n- no-operation mode, cause we just want info, not to mess with the card
Putting those arguments together with the path to the FAT32 disk, replacing
mmcblk0p1 with the path on your system:
% sudo dosfsck -v -n /dev/mmcblk0p1 fsck.fat 4.2 (2021-01-31) Checking we can access the last sector of the filesystem There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 65:01/00 Not automatically fixing this. Boot sector contents: System ID "mkfs.fat" Media byte 0xf8 (hard disk) 512 bytes per logical sector 32768 bytes per cluster 64 reserved sectors First FAT starts at byte 32768 (sector 64) 2 FATs, 32 bit entries 31293440 bytes per FAT (= 61120 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 62619648 (sector 122304) 7821417 data clusters (256292192256 bytes) 16 sectors/track, 4 heads 2048 hidden sectors 500692992 sectors total FATs differ but appear to be intact. Using first FAT. Checking for unused clusters. Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Checking free cluster summary. Leaving filesystem unchanged. /dev/mmcblk0p1: 704 files, 186552/7821417 clusters
If you look look closely, you’ll be able to find the cluster size, or you can just pipe the output to grep to get something less noisy:
% sudo dosfsck -v -n /dev/mmcblk0p1 | grep 'bytes per cluster' 32768 bytes per cluster
Would you look at that, turns out my card was already formatted to use a 32kb cluster size. Also turns out that’s evidently the default cluster size for most disk utilities, so seems like you may have to go out of your way to set it to something other than 32kb.