Hacker News new | past | comments | ask | show | jobs | submit login

The major problem is not disk write speed, which we can all agree sucks, but longevity and lifespan when used as a system boot disk and also containing /var and similar. The write wear leveling on a u3 microsd card is nowhere near as good as even a $50 consumer class ssd.

Small single board computers should move towards m.2 2280 nvme drive support, or at least one sata 6 gbps interface.




The Pi steals the lion’s share of the attention the in the cheap SBC space, but there are plenty of alternatives that have better storage solutions out there. I too grew fed up of SD card issues.

I always see the argument “but the Pi has the best community support!” trotted out, and I don’t disagree. However, it’s all normally just sane Linux distros on the Pi at the end of the day. Whatever instructions/advice someone has written for a given Pi project will likely be applicable on a non-Pi board anyway.


I think it depends a lot on your use case. If you just want a dirt cheap HTPC, then yes, there are lots of SBCs that will fit the bill, but the RPi also has a hardware add-on ecosystem around its particular camera and GPIO/SPI/I2C/I2S availability, and even though lots of other boards have those things available and broken out too, you're going to have to be willing to do a lot more leg work to get it all hooked up properly and working for a different SoC.


SD card performance on the Pi <4 is so poor (and the bandwidth is shared with the USB controller anyway, I think) that you might as well use an attached USB hard disk; even for booting.

Jeff's benchmarks are accurate in my experience. If you try saving single images from a camera at even 5-10fps, the card quickly bottleneck and you start dropping frames. If you buffer and store (in my case 16-bit raw), you can essentially saturate USB bandwidth if you're also using a USB camera.


We've got a few Pi's in office "production" (used as dashboards) and the best solution we've found it to use an SSD drive via USB. Something like a 128GB SSD drive is cheap enough, although it's about as expensive as the Pi itself.


No, the bandwidth isn't shared as both sd controllers (sdhci and sdhost) are directly accessible using MMIO (and DMA).


Thanks for clarifying that, I was never sure.


Yeah I'm always fighting both write speed and network speed limitations when I do timelapse projects with my Pi Zeros. Hopefully the I/O improvements from the 4 trickle down to the Zero form factor sometime soon!


There are SD cards rated for "high endurance" for example https://www.amazon.com/gp/aw/d/B07B984HJ5 is designed for continuous 24/7 writes such as surveillance cameras. These should have great longevity when used in a RPi.

What I would really like to see is RPi configurations optimized to reduce writes. For example mount the whole SD card read-only, mount a few essential filesystems as ramfs (/var, /tmp, /run), and have, say only one partition like /srv mounted read-write (+ noatime). If you run a webserver, and serve files off /srv you can still update them whenever with no hassle, but when the webserver is otherwise just serving the files, there should be zero writes.


That's essentially what the Nerves Project does [1]. You can boot Phoenix webserver serving static files with zero writes. The root filesystem and server code is written to one of two read-only partitions updated using an A/B scheme. Then a separate ext4 partition is RW and mounted to `/root` by default.

The trick is dealing with stateful apps (e.g. sensors) that write continuously. Power outages are painful on SD cards. Lately I've moved to a separate USB drive for writing bulk sensor data with Pi's. Then the application data partition on the SD card can be used for backup sensor readings -- probably summarized data written rarely to reduce chance of SD card corruption. Mostly when I've had SD card issues its with just the RW partition, specifically the database I'm using gets checksum errors. Never had one not boot due to a bad SD.

Though I'm contemplating trying out BTRFS mirror'ing on a single USB drive, though bcachefs looks promising once mainlined. It's cheaper to buy two 32GB USB Thumbdrives (mirrored) or even a full usb based ssd than buying an SD card with a large amount of SLC based storage. The new Pi's will be a significant upgrade in speed with external USB SSD/Thumbdrives.

1: https://github.com/nerves-project/nerves/blob/master/docs/Ad...


Given the market segment, theoretical longevity and lifespan are not a concern - both on the producer side, who has to put more expensive chips, and on the consumer side, who has to pay for the chips and the media (SD cards are extremely cheap).

Moving up in the market segnment there are in fact higher-end solutions:

  - the Odroid XU4 has an eMMC port (for those who want a compact solution but don't care
    about long-term durability)
  - again, the XU4 supports a SATA bridge
  - the Odroid has both eMMC and SATA ports
(I mention Odroid purely because I'm familiar with the products)


Corrections:

  - the Odroid XU4 has an eMMC port [...] a compact *and faster* solution [...]
  - the Odroid *H2* has both eMMC and SATA ports


Would be nice to see an NVMe slot on one of these things. I’m guessing there aren’t even enough PCI Express lanes on RPi 4 to do that today.


Or at least support USB boot out-of-the-box. At lease someone could buy a USB 3.1 M.2 enclosure and boot from that if they need the stability and speed without modifying the form-factor or increasing the price.


I expected they would have at least added a EMMC connection by now. With the improvements from the new faster EMMC options it isn't even that slow.


Exactly, who cares about speed when all the microSD cards I try eventually become corrupt due to poor controller logic.


Try an ‘industrial’ flash card. I outfitted my pi with a SwissBit microsd and haven’t had any disk problems since.


That'd be an interesting feature to see but I'm sure it'd also really run up the board cost...



If you want longevity, but an SLC card.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: