RPi3 server with SSD

[TerryE]

This is yet another RPi thread.  Some of you might be interested.  I was originally intending to use 2 RPis for my HA, but on reflection I have decided that one of the two is hardly doing anything and it actually makes life simpler to collapse all of the functions down onto one RPi.  I had considered moving to a more powerful SBC (such as the one discussed in this companion thread)  but in the end I decided to stay with an RPi for now.  This will host

• a MQTT broker,
• a MYSQL (InnoDB) database,
• a limited lighttp webservice and
• a Node RED instance, 

all on a minimal headless server -- that is no desktop and only SSH access for login and file transfer.

 

I want to keep battery backup (mainly for orderly shutdown on power outage) and some reliable mass storage device and this really means SSD if I am going to be battery backup friendly

 

So I really want to cover two topics here:  using DietPi to provision my server, and some issues around SSD performance.

• DietPi.  This makes building the Pi a doddle.  You download and image onto an SD card a smallish (<100Mb unpacked) provisioning file system and if you want a headless install there is a single config file, /boot/dietpi.txt, that you need to edit to select your Wifi credentials, some passwords and software that you want to install.  Plug it into the RPi, turn it on and come back 15 mins later and you can SSH into the build server.  There is a simple terminal-based menu system for doing further configuration S/W installation, etc and also maintenance functions such as move the root partition onto a USB-based device, e.g. memory stick, HDD or SSD. and so configuring the SSD is a couple of click operation.  Once you've done this, you still have /boot on the SD card, but the OS and user directories run off the SSD (in my case). All very good.

• SSD performance.  Because of the underlying page-base nand storage technology, this does have some significant performance and lifetime issues if not actively addressed by the OS and the filesystems on the SSD.  The RPi uses a Linux family OS, and both the OS kernel and the main FS used on the RRi (Ext4) are SSD aware, and the OS includes a TRIM function to enable the SSD controller to align its garbage collection to the use of the file system.  Without this, the performance of the SSD can significantly degrade over time as unused clusters my contain garbage and the whole page need erasing and rewriting to do a write. (This is a good article explaining how TRIM works)

The gotcha that I've found is that the TRIM command is a native ATA one, and Linux does support this for directly attached SATA disks.  However, it is not in the standard USB FS interface, so the USB-to-SATA chip needs to support ATA pass-through, and the Linux kernel driver for these USB chips don't yet support this.  So the nice features which prevent SSD performance degradation effectively don't work with RPi's USB attached SSDs.  Bugger.

 

 

Edited February 2, 2022 by TerryE

[Guest Alphonsox]

@TerryE - Thanks for the info, I was unaware of the existence of Dietpi

Does the same issue exist for a directly connected SD card ?  Do you actually need an USB mounted SSD or could a large (128G) card be used instead ?

 

EDIT - it seems that some interfaces may support TRIM

http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html

[TerryE]

SD cards have a very primitive controller and don't support TRIM.  Whatever the weakness of SSDs they are materially more reliably than SD cards if you are using them as a RW device. 

 

Whilst the RPi3 can now boot off a USB attached FS, I find it just easier to leave the /boot partition on the SD.  It's almost never written to, so this is fine. 

 

If you do want to use an SD for R/W then the trick is to use a reasonably large one so that the FS utilisation is small.  Also from what I gather one of the main reasons for failure of an SD isn't wear exhaustion, but rather a power fail whilst the RPi is in the middle of a write to the card.  You can avoid this entirely with a small battery backup hat which can keep the RPi up for 10 mins say and does an orderly shutdown after 5min without power, so that any unwritten buffers are properly flushed to SD and written through before the FS is properly dismounted.

 

[Jeremy Harris]

I've already had one SD card failure with a RPi, so now completely boot from a HDD, with nothing on the SD card. 

 

The real problem is the RPi not having anything but USB interfaces, even the SD card is on the USB bus, I believe.  I've been tempted by some of the newer SBCs that have a SATA or eSATA port, as at least you can then have much better control of any HDD/SSD that's plugged in.  The problem is that the RPi has such a massive user base, so if switching to one of the other SBCs then there's no where near as much support available.  I'm still tempted to try, though, and might get something like a Banana Pi to play with.

[Onoff]

Could you not use 2 or more SD cards in a RAID array to guard against failure?

[Jeremy Harris]

2 minutes ago, Onoff said:

Could you not use 2 or more SD cards in a RAID array to guard against failure?

 

AFAIK, this isn't possible.  You can certainly boot from a different SD card, plugged into one of the USB ports, but I don't think you can run a RAID controller over USB, and bear in mind that the SD card slot and the USB slots are all USB 2.0 on the RPi, so not that fast. 

 

The problem with SD cards is primarily as @TerryE has already said, their internal controller doesn't give the full of degree of freedom needed to manage locations in the storage. 

 

Using a board with a dedicated storage interface, either SATA or eSATA, means that the operating system can have better control of the filing system, and it is also massively faster.  The USB 2.0 interface to the SD card is a fairly hefty bottleneck, in fact the USB 2.0 interface in general is a bottleneck.  I've been using a RPi 3 as a file server, with a 1 Tb HDD plugged in to one of the USB ports, for a while.  The RPi boots directly from that HDD, which is a LOT quicker than booting from the SD card, but file transfer speeds are still slow, because of the USB 2.0 speed restriction. 

 

It's a shame that the RP Foundation have no plans to introduce any new versions, as an RPi 3, with a SATA port and USB 3.0, but with all the other stuff as-is, would be a big step change and make a lot of people happy, I'm sure.

 

[Onoff]

I was thinking something like this:

 

https://the-gadgeteer.com/2016/03/17/turn-10-micro-sd-cards-into-a-sata-ssd-drive/

[Jeremy Harris]

2 minutes ago, Onoff said:

I was thinking something like this:

 

https://the-gadgeteer.com/2016/03/17/turn-10-micro-sd-cards-into-a-sata-ssd-drive/

 

 

The snag is there is no SATA interface available on the RPi, only USB 2.0.

[TerryE]

@Onoff na. Bad idea. It's cheaper to do it properly and get an SSD.

[SteamyTea]

I once saw, on the internet, someone that used pen drives to make a RAID for his Mac.  Says it all really.

 

But I found this:

 

[TerryE]

Yup you can do this, especially if you use btrfs, but a Kingston UV400 SSD + case costs around £50.  Speed and reliability are worth more to me than a few £10s bought-in cost savings.

 

I'd be happy with USB3 if the linux driver supported ATA pass-through.  Failing that, it's OrangePi or BananaPi. These also have the benefit of supporting 2Gb RAM.