It sucks. I did one with 20 of these. It was be slow and crash in about a year with failures. Not worth the time unless you already have a ton of these lying around and you like building stuff like this.
Care to share any details? Curious how you actually set up the access to the array (like just plug in a bunch of USB microsd readers and wrote a driver to handle the array itself?) as well as the config you used for the array, like which raid mode and most importantly, if striping, if you matched the stripe size to the microsd read block size. A mismatch would result in poor performance, though I could also see it performing poorly even if it was set up ideally, though in theory an ideal setup should have been able to get 20x the throughput for large continuous reads and writes, though random access and latency wouldn't improve.
It also requires the bus(es) the USBs are on to support the total saturated throughput, though I don't expect you got anywhere close to saturating the USB link (unless maybe you did on pretty old hardware).
I wasn't aware that that existed. Guessing it didn't also raid each of the inserted drives, so it would have at best given 2x microsd performance, though at worst it would be as slow as your slowest one. Actually mismatches of performance from microsd to microsd could have even cause further performance issues if the raid controller assumes equal performance so that the read responses can be interleaved with some small amount of buffer space. It could mean one getting too far ahead of the other would end up requiring transactions to be re-issued. Even if they were all identical, I wouldn't expect them to degrade at the same rate.
Though now I am curious about how well a large number of microsd cards would perform if set up in an array that striped/mirrored across all of them rather than batches of them, with sufficient buffer space to absorb perf differences between the cards (meaning it would still be held back by the slowest cards but not to the point of thrashing, if that was an added factor in your setup).
The biggest problem was heat. If you used the drive for longer than a few minutes the the speed dropped to a crawl.
The second part was the caching issue, it can read really fast but writing was very inconsistent. Small files were quick, large ones showed down a lot.
The second problem was the reliability. These micro sd cards aren't meant to be used for constant writing. Think about those dash cams with microsd, if you have then set to constant recording the micro sd cards usually fails in just a few years. Now imagine you have 20 of these. It's like a ticking time bomb.
But overall, it was fun to give these little microsd cards a new life. It's good enough to play games on, at least games from 10 years ago when i did this.
40 replies
Now he's exFAT
"Ah, finally a new format the everyone supports!"
*goes to next computer*
Not supported
At some point you just say "fuck compatibility", and format the card with F2FS without a partition table.
F2FS mentioned!
I don't understand. That's compatible with all my devices.
Hah, I see what you did there. Noice!
Would have been better as a CD-ROM...
Seeing as how he got ripped.
...it means File Allocation Table, adding the 32 was just insult to injury...
FAT12 and FAT16 were a thing as well.
...i'm not interested in teens...you from the 80's?.../s, really sorry
12 isn't exactly teen, is it? ;) Must I have lived through it to know about it? :P
What do you mean twelveteen isn't a teen?
I fear what that could mean for someone being eightteen
Sorry, but, what? pedantry says teen is 11-20, weird meter says:what?
I think it's usually 13-19
Eleven.
Twelve.
Thirteen
Fourteen
Fifteen
Sixteen
Seventeen
Eighteen
Nineteen
Twenty
What is your condoning level?
I don't know what that is tbh
I remember having to implement fat12 in assembly. Good times...
Should I add that to my backlog of things I want to but will never start?
Nope, there's already littlefs, FatFs and also lwext4 for microcontrollers.
Only if you want to learn how the simplest file system works. I did it in uni, not super useful for practical purposes.
Repo?
It was a Uni project, back then even svn was a new and scary tech. I doubt I have a copy.
Fair enough, I had to try.
Dang. 1,000,000,000,000 bytes vs 1,440,000* bytes. And in about 1/100th the size!
Fatty took more bites and still lost weight.
Soemtimes less is Moore's!
I think you mean 1,440,000 bytes
Aw shit I sure do 😅
I'd love to make a RAID with 2-3 of those microSDs.
It sucks. I did one with 20 of these. It was be slow and crash in about a year with failures. Not worth the time unless you already have a ton of these lying around and you like building stuff like this.
Care to share any details? Curious how you actually set up the access to the array (like just plug in a bunch of USB microsd readers and wrote a driver to handle the array itself?) as well as the config you used for the array, like which raid mode and most importantly, if striping, if you matched the stripe size to the microsd read block size. A mismatch would result in poor performance, though I could also see it performing poorly even if it was set up ideally, though in theory an ideal setup should have been able to get 20x the throughput for large continuous reads and writes, though random access and latency wouldn't improve.
It also requires the bus(es) the USBs are on to support the total saturated throughput, though I don't expect you got anywhere close to saturating the USB link (unless maybe you did on pretty old hardware).
I used this to make a single sata drive, plugged two is them into my raid sata ports on my hdd and combined then into one raid zero hd.
The biggest slowdown was the memory controller, they are cheap and not very fast on these things. I was no wear near the limit of the sata ports.
I wasn't aware that that existed. Guessing it didn't also raid each of the inserted drives, so it would have at best given 2x microsd performance, though at worst it would be as slow as your slowest one. Actually mismatches of performance from microsd to microsd could have even cause further performance issues if the raid controller assumes equal performance so that the read responses can be interleaved with some small amount of buffer space. It could mean one getting too far ahead of the other would end up requiring transactions to be re-issued. Even if they were all identical, I wouldn't expect them to degrade at the same rate.
Though now I am curious about how well a large number of microsd cards would perform if set up in an array that striped/mirrored across all of them rather than batches of them, with sufficient buffer space to absorb perf differences between the cards (meaning it would still be held back by the slowest cards but not to the point of thrashing, if that was an added factor in your setup).
The biggest problem was heat. If you used the drive for longer than a few minutes the the speed dropped to a crawl.
The second part was the caching issue, it can read really fast but writing was very inconsistent. Small files were quick, large ones showed down a lot.
The second problem was the reliability. These micro sd cards aren't meant to be used for constant writing. Think about those dash cams with microsd, if you have then set to constant recording the micro sd cards usually fails in just a few years. Now imagine you have 20 of these. It's like a ticking time bomb.
But overall, it was fun to give these little microsd cards a new life. It's good enough to play games on, at least games from 10 years ago when i did this.
The usb part that actually stores the data is actually similarly small in size,the port however needs to be that size
Yeah, yeah, the stubborn handles that just won't go away, I've heard it before.
Has he tried losing weight?
In real life it's the microsd the one calling the USB fatso.