https://sigwait.org/~alex/blog/2024/07/01/the-cheapest-nas.html Alexander Gromnitsky's Blog Search 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. Item Price, EUR Comment SBC 20 HDD enclosure 12 3A Power Supply 5 Micro-USB cable 3 4 bolts, 12 nuts 0 I think the ones I found are older than me TTL to USB dongle 3 Optional, the board has an HDMI output Total 43 (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. [innards] [rear] After connecting the TTL-to-USB dongle to the board's GPIO [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 52421.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. Tags: oiti Authors: ag avatar [rss] Subscribe [?] [?] Authors [?] Tags [?] Please help Ukraine win the war! Donate to Come Back Alive foundation. (Read about the foundation in Wikipedia.)