3 ms·

It's a bit finicky to get working/set up (make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux), but you can boot the Pi4 o

It's a bit finicky to get working/set up (make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux), but you can boot the Pi4 off of a USB SSD now. Still might not be what you need, but it's way better than booting from an SD card.

jmuguy 5y ago
I've gone that route before. My main thought is that it seems like the Pi itself should have more robust/longer lasting storage just be default at this point.
- zozbot234 5y ago
  What's more robust and longer-lasting than SD and USB sockets? Flash storage is inherently unreliable and prone to failure, so keeping it on pluggable media is the sensible thing to do.
  - jmuguy 5y ago
    Well I thought eMMC, but as you indicated that's basically just a SD card soldiered to the board (which I didn't know). So NVMe? I didn't think this was a really contentious idea. I've had several Pi projects that I needed to mess with because the SD card died. So it seems like a logical evolution would be for the Pi to have more robust storage out of the box.
    - SahAssar 5y ago
      I think most people with those requirements treat the SD card as a bootloader and keep the main system on a USB connected SSD (or make the system not write-heavy while still only using the SD). It'd be nice to have a rpi that supported NVMe (or just more reliable boot from USB) but I can see why that is not exactly in-scope. IIRC the most destructive thing to a rpi that is SD-storage only is excessive logging. If you use journald (part of systemd) you can configure it to only keep a small rotating in-memory log, if you use traditional textual logs you can probably do something similar by mounting a in memory fs on the log path. If you need to keep logs for longer (or between boots/crashes) it's probably good to not use the SD-storage for that. IIRC Tesla had problems with their eMMC storage because they used it for log storage and I've worked on related parts for IoT devices that used SD-cards. I'm not sure how user-friendly/defaulted all of this is on the recommended rpi distros.
      - Syonyk 5y ago
        This is how I run mine - SD for boot, USB SSD for root. You can run NVMe on a Pi4, sort of... if you replace the USB3 controller with a bridge PCB that routes PCIe out the USB ports properly for some other adapters. I don't recall if they got it working reliably or not. And then if you use the CM4, you can certainly have reliable NVMe. But I'm just not sure it really matters. USB3 SSDs, UAS or not (I've run into UAS issues and while you can tell the difference in a benchmark between having it and not, I can't tell the difference in end use) are more than fast enough for daily use. I've done a writeup of making a Pi4 desktop here: https://www.sevarg.net/2019/12/14/building-raspberry-pi-4-desktop/ https://www.sevarg.net/2019/12/14/building-raspberry-pi-4-de... The only real change is that the kernel now has zswap provided as a module, so you don't need to build a kernel unless you just think building a kernel on a Pi is cool (which it indeed is). It's not fast, but it's more than adequate for light desktop use. If you want more guts behind it, the ODroid N2+ is about twice as fast, for not an awful lot more money.
scottlamb 5y ago
> make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux How does one do that? I've been bitten with block-level and then filesystem-level errors, so I just recommend always disabling UAS. [1] But if you have a good way to make sure UAS is fully reliable, I'd love to update my recommendation. [1] https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#disable-uas https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...
- HideousKojima 5y ago
  Basically this list of known working adapters is your best bet: https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/ https://jamesachambers.com/raspberry-pi-4-usb-boot-config-gu... You can technically just disable UAS like you said, but you'll likely lose some drive performance. But if filesystem corruption is a concern then you're probably safer disabling it.
  - scottlamb 5y ago
    I don't think that list is good enough. I've had adapters work fine for months with UAS and then have errors. I went through a few rounds of that, disabled UAS, and haven't had problems with the same adapters for a couple years since. So I believe there are adapters out there that more or less work with UAS on Linux but under some infrequent condition (likely load-related) cause these sorts of errors. So a table of "Known Working Adapters" with notes like "Reported as working with UASP support by pierro78 in the comments" doesn't address my concern.
mypastself 5y ago
I’ve had enough trouble with SD cards and regular drives that I ended up replacing the storage for all my important Pis with external SSDs, and I’ve been pretty happy with them. I’ve found that it’s worth the price and portability trade-offs.

jmuguy 5y ago

I've gone that route before. My main thought is that it seems like the Pi itself should have more robust/longer lasting storage just be default at this point.

zozbot234 5y ago
What's more robust and longer-lasting than SD and USB sockets? Flash storage is inherently unreliable and prone to failure, so keeping it on pluggable media is the sensible thing to do.
- jmuguy 5y ago
  Well I thought eMMC, but as you indicated that's basically just a SD card soldiered to the board (which I didn't know). So NVMe? I didn't think this was a really contentious idea. I've had several Pi projects that I needed to mess with because the SD card died. So it seems like a logical evolution would be for the Pi to have more robust storage out of the box.
  - SahAssar 5y ago
    I think most people with those requirements treat the SD card as a bootloader and keep the main system on a USB connected SSD (or make the system not write-heavy while still only using the SD). It'd be nice to have a rpi that supported NVMe (or just more reliable boot from USB) but I can see why that is not exactly in-scope. IIRC the most destructive thing to a rpi that is SD-storage only is excessive logging. If you use journald (part of systemd) you can configure it to only keep a small rotating in-memory log, if you use traditional textual logs you can probably do something similar by mounting a in memory fs on the log path. If you need to keep logs for longer (or between boots/crashes) it's probably good to not use the SD-storage for that. IIRC Tesla had problems with their eMMC storage because they used it for log storage and I've worked on related parts for IoT devices that used SD-cards. I'm not sure how user-friendly/defaulted all of this is on the recommended rpi distros.
    - Syonyk 5y ago
      This is how I run mine - SD for boot, USB SSD for root. You can run NVMe on a Pi4, sort of... if you replace the USB3 controller with a bridge PCB that routes PCIe out the USB ports properly for some other adapters. I don't recall if they got it working reliably or not. And then if you use the CM4, you can certainly have reliable NVMe. But I'm just not sure it really matters. USB3 SSDs, UAS or not (I've run into UAS issues and while you can tell the difference in a benchmark between having it and not, I can't tell the difference in end use) are more than fast enough for daily use. I've done a writeup of making a Pi4 desktop here: https://www.sevarg.net/2019/12/14/building-raspberry-pi-4-desktop/ https://www.sevarg.net/2019/12/14/building-raspberry-pi-4-de... The only real change is that the kernel now has zswap provided as a module, so you don't need to build a kernel unless you just think building a kernel on a Pi is cool (which it indeed is). It's not fast, but it's more than adequate for light desktop use. If you want more guts behind it, the ODroid N2+ is about twice as fast, for not an awful lot more money.

scottlamb 5y ago

> make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux How does one do that? I've been bitten with block-level and then filesystem-level errors, so I just recommend always disabling UAS. [1] But if you have a good way to make sure UAS is fully reliable, I'd love to update my recommendation. [1] https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#disable-uas https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...

HideousKojima 5y ago
Basically this list of known working adapters is your best bet: https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/ https://jamesachambers.com/raspberry-pi-4-usb-boot-config-gu... You can technically just disable UAS like you said, but you'll likely lose some drive performance. But if filesystem corruption is a concern then you're probably safer disabling it.
- scottlamb 5y ago
  I don't think that list is good enough. I've had adapters work fine for months with UAS and then have errors. I went through a few rounds of that, disabled UAS, and haven't had problems with the same adapters for a couple years since. So I believe there are adapters out there that more or less work with UAS on Linux but under some infrequent condition (likely load-related) cause these sorts of errors. So a table of "Known Working Adapters" with notes like "Reported as working with UASP support by pierro78 in the comments" doesn't address my concern.

mypastself 5y ago

I’ve had enough trouble with SD cards and regular drives that I ended up replacing the storage for all my important Pis with external SSDs, and I’ve been pretty happy with them. I’ve found that it’s worth the price and portability trade-offs.