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
the 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.
