Alexander Gromnitsky's Blog

The cheapest NAS

Latest update: 2024-07-03 19:09:11

I wanted to replace my old trusty 'router' (with an attached HDD)--that was not working as a router, but as a network drive after flashing OpenWRT onto it--I wanter to replace it with an SBC+HDD combo.

This new device should not only preserve all the services the old one provided (samba, git, rsyncd, a dnf repo), but also perform faster, for having a potato instead of a CPU, the ex-router struggled with rsync over ssh &, being gravely RAM limited, choked when I did 'git push' commits containing binaries > 15MB.

Searching for a suitable SBC led me to libre.computer, a company I had never heard of before. At first glance, they had the el cheapo AML-S805X-AC board I needed:

• LAN port (but 100 Mb only);
• 2 USB-A (but 2.0 only);
• 4-core ARM Cortex-A53;
• 1 GB RAM;
• booting from an USB;
• up-to-date Debian;
• easy to buy without hunting it down.

100Mb may seem like a joke nowadays, but the main purpose of such a toy NAS for me is to keep a copy of a directory with ~200K small files. Having 1Gb would only marginally improve the syncing speed even if the SBC supported USB 3.0.

But this is just a board. I also needed an hdd enclosure with an external power supply (for the device provides up to 900mA for each USB-A), at least 3A power supply & a micro-USB cable that can handle 3A.

(I didn't include an HDD in the table, for I presume everyone has a couple of them lying around.)

When I bought the HDD enclosure, I didn't read the description carefully & thought it was going to be a small plastic container for 2.5-inch drives, but when the package arrived, it turned out to be a box for 3.5-inch ones. Hence, I decided to shove the SBC into it too.

After connecting the TTL-to-USB dongle to the board's GPIO

& typing

$ sudo screen /dev/ttyUSB0 115200

one of the 1st readouts appeared as:

U-Boot 2023.07+ (Nov 03 2023 - 15:10:36 -0400) Libre Computer AML-S805X-AC

Model: Libre Computer AML-S805X-AC
SoC:   Amlogic Meson GXL (S805X) Revision 21:d (34:2)
DRAM:  512 MiB (effective 1 GiB)

What does the last line mean exactly? After I dd'ed Debian-12 onto a flash drive, free(1) said it saw 1GB. Anyway, libre.computer has an official OS image, based on stock Debian:

$ fdisk debian-12-base-arm64+arm64.img -l
Disk debian-12-base-arm64+arm64.img: 2.25 GiB, 2415919104 bytes, 4718592 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x71f3f7cf

Device                          Boot  Start     End Sectors  Size Id Type
debian-12-base-arm64+arm64.img1 *      2048  524287  522240  255M ef EFI (FAT-12/16/32)
debian-12-base-arm64+arm64.img2      524288 4718591 4194304    2G 83 Linux

Yes, it has an EFI partition with the MBR layout! The 2nd partition is btrfs (supposedly it's faster & more gentle to flash storage than ext4; no idea if both claims are true). You can examine its contents via:

$ sudo mount -o loop,offset=$((524288*512)) debian-12-base-arm64+arm64.img ~/mnt/misc

This partition gets auto-resized on the 1st boot to fill the rest of the free space available on the drive. Doing this on USB dongles proved to be a miserable experience: of the 3 I had available, one permanently got stuck on resizing, and another, despite finishing the operation, became so sluggish afterwards that a 20-year-old PC would've felt snappier.

This is I didn't like at all. There is no repo with from which the OS image gets generated. The explanation is bizarre:

"The distribution builder is a proprietary commercial offering as it involves a lot of customer IP and integrations so it cannot be public."

but with an consolation advice:

"If you want to study them [images], bootstrap and do a diff. We don't make any changes to the standard distros outside of setting a few configs since we're not distro maintainers."

Make of it what you will.

Then I connected the HDD enclosure to the board. This time, the process went much, much faster (though there were still some unexpected delays in random places). Right after logging in, I started getting uas_eh_abort_handler errors from the kernel. It turns out I got one of the worst HDD enclosure innards possible, if you believe reviews from the interwebs:

$ lsusb
Bus 001 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The remedy is to turn UAS off via adding usb-storage.quirks=152d:0578:u to the kernel cmdline. It did help, the delays went away, although 'benchmarks' became hardly thrilling:

$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
$ sync; time sh -c "dd if=/dev/urandom of=1 bs=500k count=1k && sync"; rm 1
1024+0 records in
1024+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 15.1014 s, 34.7 MB/s

real    0m21.876s
user    0m0.001s
sys     0m7.976s

which means $\frac{524}{21.876}=23.95$ MB/s on an ext4 partition.

Would I recommend this setup? I wouldn't. One of the reasons I've chosen the path with an SBC instead of a common micro-ITX route is to save on power consumption. If you don't have similar problems, I see 0 reasons to struggle with such a finicky Chinese device.