Hacker News Reader

Comment by walrus01 | Hacker News Reader

Raspi cannot be used for a semi serious server application due to microsd card write wear issues. All other methods of attaching external storage by USB bus to an rpi are not reliable or suitable for this sort of purpose. Nowhere near the longevity of something with a native sata or m.2 SSD interface and a real SSD.

View on HN

There's also the added complication of the fact it's an ARM based device so in some cases you might run into compatability issues, or testing your container locally becomes problematic.

It's definitely getting better though

"Raspi cannot be used for a semi serious server application due to microsd card write wear issues."

As an end user, I run a personal authoritative DNS server that has small RAM requirements. The RPi (or other SBC) boots to a mfs mounted root, then mounts all directories as tmpfs. Then I remove the SD card.1 As such, the logs for this server, which are automatically rotated and do not exceed 5M in total, are written to RAM.

1 I only use the SD card to boot. The only files on the card are a bootloader, a bootloader config and two kernels, each with an embedded filesystem. If updates are necessary, I make them to one of the kernels at a time. The other is the backup. The bootloader and bootloader config lets me specify which kernel to boot.

Does that remain true if you grossly over-provision the SD card? Use a 64GB card for 1GB of data and you have a lot of wear leveling space.

The write lifespan in DWPD on any sd card is a tiny fraction of the expected lifespan of even a cheap $55 consumer SSD.

Part of the problem is that even if you only write 1GB per day the card is highly likely to reuse the same sectors over and over.

Don't most modern SD cards contain some wear leveling logic?

I did a bunch of research on this a while back and the conclusion I found was: yes, but buy name-brand better rated cards to avoid cheapo cards that do not do wear leveling or do it very badly.

It's nowhere near as good as SSD drives, but it's better than just a naked flash chip... unless I'm wrong.

Yes, but it's not enough.

Even the brand name cards aren't worth shit; you need to buy "industrial" cards.

Source: tried to get a root filesystem to work on name brand SD cards for a high availability product.

Hey if you see this can you answer one more question:

How much abuse was your high availability product delivering to these cards in terms of writes? Was it something like a video recorder, database, cryptocurrency, or some other application that did large amounts of write I/O?

I ask because we're about to ship something that uses SD cards, but the I/O is very low. It's a network appliance and doesn't do anything locally that is high write throughput.

We weren't beating up the SD card with heavy writes. It was for a robotics controller, so just sort of normal, low throughput logging.

We even saw SD cards screwing up in RO mode in fact, from major brands. Trust me, you want to swap out for an industrial card in your BoM.

Have you tried things like jffs2? Do they help?

jffs2 runs on raw flash. SD cards have an abstraction layer in front of the flash to make it look like a normal block device and jffs2 isn't usable.

...the card is highly likely to reuse the same sectors over and over.

One would have expected this to be an area of focus for RasPi developers? Surely some driver could be updated to avoid this?

The Linux kernel in raspbian treats the SD card like a normal block device. I'm not aware of any special optimization for write wear leveling at the OS level, or on the board's sd card controller.

SD card wear-levelling is usually supposed to be handled on the controller inside the SD card. SD cards aren't like having raw access to flash, you basically write over SPI and the controller in the SD card decides where to actually put it.

This talk about SD cards is really great and explains some of this:

https://youtu.be/r3GDPwIuRKI?t=197

Fantastic talk, thanks for the link!

Not without making the card unreadable in other systems.

And even then I'd be surprised if you could game physical sector offsets by playing with the virtual offsets you have access to.

Reply on news.ycombinator.com