At first, the yard camera worked fine, but a few days later the stream of JPEG images would unpredictably stall. I connect to it through a public-key SSH session and, sometimes, the login would stall for tens of seconds and, with a session set up, various exciting operation like, say, htop would unpredictably stall; if I waited long enough, they’d complete normally.
It’s a known-good card from a reputable supplier, not that that means much these days. The camera flash highlights the gritty silkscreen (?) texture of the orange overlay, but the production value seems high enough to pass muster.
Popping the card in my desktop PC showed:
- It remains functional, at least to the extent of being mount-able and write-able
3probe --time-ops /dev/sdbshowed it still held 16 GBfsck -fv /dev/sdb[12]shows no problems- Both partitions looked good
So I shrank the main partition to 7.5 GB, copied the image to the desktop PC’s SSD, fired up the Token Windows Laptop, ran the Official SD Card Formatter, and discovered that it thought the card had only 63 MB (yes, MB) available. That’s the size of the FAT boot partition, so I returned the card to the desktop PC, unleashed gparted on it, blew away the partitions, reformatted the whole thing to one 16 GB FAT32 partition, and stuck it back in the laptop, whereupon the Official Formatter agreed it had every byte it should.
A format-with-overwrite then proceeded apace; the card doesn’t support format-with-erase.
Back in the desktop, I copied the saved image back onto the card which, en passant, blew away the just-created FAT format and restored the Raspbian partition structure. The 8 GB of that copy proceeded at an average 12.1 MB/s. I did not watch the transfer closely enough to notice any protracted delays.
Back in the Pi, the card booted and ran perfectly, sending an image every second to the laptop (now running its usual Mint Linux) on the guest network:
SSH sessions now work perfectly, too, and commands no longer jam.
So it seems a good-quality MicroSD card can experience protracted delays while writing data, to the extent of tens of seconds, stalling the Pi in mid-operation without producing data errors or any other symptoms.
It’s not clear the Official Formatter does anything that simply copying the image back to the card wouldn’t also accomplish, although overwriting the entire 16 GB extent of the card exercises all the cells and forces the card controller to re/de/un/allocate bad blocks. If, indeed, the blocks are bad, rather than just achingly slow.
Moral of the story: Don’t use MicroSD cards as mass storage devices, at least not for industrial applications that require consistent performance.
The Smell of Molten Projects in the Morning 
Odd that the formatter pays any attention to partitioning. I’ve had a few cards and drives that have weird boot partitions, and spent a while to find the proper incantation to make something that will work on both windows and real computers. Some situations need MBR, others need a GUID Partitioning Table.
Aye! I’d expect the Official Formatter would extract config data directly from the card hardware and pay no attention to the MBR, but that’s not what happens.
That’s a handsome flock of wild turkeys. What do you feed them?
They’re responsible for their own chow! Minus the snowcover, they harvest bugs & seeds all over the “lawn”. They often scratch the mulch out of the herb plantings along the garden fence over on the left and sometimes taste those leaves; we think of them as self-seasoning turkeys.
In my experience (with uSD for a BeagleBone Black), Windows can only see the first partition – which may explain the 63MB result. That resulted in a non-traditional partitioning scheme which made the first partition the largest, “data” partition.
I’ve stumbled over that gotcha a few times and, at one point, installed a Windows driver making
ext2filesystems available. IIRC, it didn’t work particularly well and didn’t handle the journaling inext3filesystems; that was quite a while ago, though.In the other direction, the Microsoft
ExFATfilesystem, in all its proprietary glory, causes vast heartache & confusion in my Sony HDR-AS30V helmet camera. The camera presents the card as a USB mass storage device, but routinely kills theexfatFUSE driver stone cold dead. Sticking the card directly into a USB reader, however, works perfectly through the same FUSE driver, so that’s what I do now.