The final NAS setup

This is a follow up article to my previous post on the NAS upgrade to the Biostar FX9830M motherboard. As soon as I received all required components, I spent the first available evening to assemble the new setup. As mentioned previously, I decided to utilize my old InWin BM639 case instead of buying a new one to save the costs. In the end, I believe, it may even stay as a permanent solution, since I am pretty satisfied with the end result. My final setup is:

• Biostar FX9830M motherboard with AMD FX-9830P Bristol-Ridge APU/CPU.
• 2x G.SKILL F4-2666C19S-8GNT 8GB RAM (16GB RAM in total).
  
• Kingston HyperX FURY SHFS37A/240G SSD for the system OS.
  
• 2x Toshiba MG04ACA600E 6TB hard drives for the data.
• Dell QLogic 57810 dual port 10Gbit SFP+ network adapter (Dell 540-BBGS) attached to switch using passive copper DAC cables.
  
• InWin BM639 case with 160W (IP-AD160-2) PSU.

Dell 540-BBGS 10Gbit SFP+ network adapter

Motherboard placement to the case

I hit the major obstacle as soon as I tried to place the motherboard inside the case. It is 1.3 cm wider than mini-ITX/mini-DTX standard, thus it was hitting internal PSU. The case hadn't enough space in between to fit. Fortunately, it provided an option to remove just the top part of the case, which gave me an opportunity to exchange the PSU position on the top of the case instead. The stability of such placement comes from the fact that cables are connected pretty tight to motherboard and the PSU has a slide at the bottom by design, which allows to fix it at one corner of the case. It is a workaround and it is not the best solution definitely, but it works pretty well. Once PSU obstacle was solved, the motherboard fit in perfectly. PCIe interface occupies the second extension slot by design, thus only single slot cards can fit (though, by removing HDD cage, likely two slot low profile cards can be used). There are possible alternatives for PSU placement as well I believe to avoid the external placement, but they likely require some modifications to the case. I may investigate those options some time in the future.

Biostar FX9830M VER6.0 motherboard

Placing the hard drives

The second obstacle was to fit two 3.5'' hard drives and one 2.5'' SSD inside. By design it has one 3.5'' cage for HDD. Besides that, it was supposed to have the 5.25'' ODD cage as well, which occupies a big part of the front side of the case, however I likely lost it over the years (I replaced it with the big fan years ago). Because of this, I needed to think out of the box a bit on how to utilize space and, if possible, to avoid external placement. Regarding the SSD drive, I was initially planning to replace it with the Sandisk Extreme Pro 3.0 USB flash drive placed internally using USB 3.0 pin header, but it appeared that pin header is protruding too much to the left, thus hitting the CPU fan. What is more, I wasn't sure if flash drive is not too long vertically as well. Because of this, I decided to stay with Kingston SATA SSD. It had its own challenges because of physically damaged SATA port, but I successfully placed it vertically on top of 3.5'' cage by using holes designed to fix 2.5'' drive. Vertical position was required to avoid the bending of drive's SATA port by the rounded metal edge on the top of the HDD cage. Fortunately, this position wasn't obstructed by the network card as well, though it makes access to it a bit more complicated. The first HDD was placed in the cage itself as designed by the motherboard, thus it didn't pose any issues. Finally, I fixed the second hard drive on the original position of the PSU by fixing it with two screws on a back side frame of the case. Thus, all the drives were successfully placed inside the case, leaving only PSU outside of it. In theory, I still can even add one more drive on the front side instead of the front fan. It may affect the airflow inside the case though, because of this, such setup would need careful testing, especially in the summertime.

Toshiba MG04ACA600E 6TB HDD

As a side fact, two SATA ports are provided by the CPU chipset, another two by ASMedia ASM1062 controller. Non of them provide RAID support. Like I mentioned before, the second SATA port is also connected with the NVMe slot, thus only one of them can be used at the same time.

Network card needs low profile bracket

The final issue was caused by the fact that Dell network card wasn't supplied with the low profile bracket, though it is easily replaceable by the design (standard screws are used). Because of this, I needed to order one from the eBay, while placing the card without it temporarily. I was concerned if it would not easily pop out of the PCIe slot, luckily, however, it stayed very firmly in the position even during cable insertion/removal process.

The final arrangement can be seen in the picture below (before cable management):

Software adjustments

Software wise the Artix Linux didn't boot out of the box, but it was solved simply by recreating initial ramdisk environment, which had also been the typical way to resolve an unsuccessful update process in the past. To my surprise, the SSD drive worked very stable on the new system, despite its damaged SATA port. I didn't experience any boot issues, I could use all the HDD utilities like smarctl, hddtemp without causing system to stall! What is more, it finally utilized its full bandwidth potential, which was very noticeable during upgrade process. 

As initially planned, I replaced NetworkManager service with the dhcpcd and netifrc combination. It was a pretty simple procedure, since only /etc/conf.d/net file required few additional lines to setup bonding interface by the provided example. Once network was ready, I tested copying files between two systems with 10Gbit network, it reached around 165MB/s, which is considerably better than previous speed ranging from 40 to 70MB/s depending on network controller, but likely limited to hard drive capabilities. Because of this, RAID0 setup may be beneficial to increase download speeds even more, just it doesn't seem necessary for me currently. It is also easy to notice snappier file browsing experience. Additionally, I used iperf3 network testing utility which reached ~6.25 Gbit/s between two systems. 

iperf3 testing results

Finally, I could remove all the workarounds applied for the previous system, including enabling the kernel updates again.

BIOS 

The motherboard uses UEFI BIOS with the typical graphical setup controlled by keyboard or mouse. It does not provide as much options as as you may expect from usual desktop gaming motherboard, but it has some specific options which are likely suitable for a business environment and power users (TPM, security, virtualization). For my specific case, I probably mainly missed more controls over fan speed and other power saving features. The motherboard fan is usually very silent but can become noisy on high CPU usage. Also, I didn't find an option to disable main AUDIO device (Realtek ALC887) (except the one from the GFX device). Dell network card supports EFI, thus I changed Network device to prefer UEFI boot instead of legacy one. BIOS provides an option to choose boot device by clicking F9 or enter BIOS flasher with F12 (no BIOS updates are available as of yet). In general, it is still an improvement over old legacy BIOS in Jetway motherboard but may disappoint more demanding people.

I also made a mistake, once I disabled internal NIC controller. It changed link's enumeration number from enp3 to enp2 which I failed to notice initially, thinking it's a possible BIOS bug and reporting it to Biostar. Actually, only simple network reconfiguration was needed.

FX9830M BIOS main screen

Conclusion

In conclusion, the full upgrade process from the hardware side to the software one went quite smoothly. The motherboard proved to be almost compatible with the Mini-DTX cases, with the PSU placement being a major concern. In my case, I resolved it quite easily due to highly modular case design. The final result is considerably stable and faster system with the big potential to utilize it in few different ways, which were not possible previously. I still plan several improvements like data encryption and cold backup in the near future. I am also waiting for the low profile bracket for the network card and a low profile COM bracket which will occupy the upper empty slot (I use serial console in some occasions) to complete the setup. Considering the successful setup with the InWin BM632 case, I started to have doubts about the need of replacing it with Fractal Design Node 304 or similar case, as I initially envisioned. I believe, I will likely look into all other options first before doing such purchase. As of today, the main concerns are to reintroduce double backups, better secure the data and utilize the new system for routine actions which I am doing either manually or using scripts. And hopefully, the system will serve me no less than the one it replaced!

2019 in review

Starting last year I resumed writing yearly review after a long break. Since 2019 was no less active in various personal computer related projects, I believe it may start a tradition of such retrospective reviews for the years to come. So without further ado, I will move on the last year's activities.

Downgrade from Radeon RX 460 to Radeon R7 370

For almost two years, I used the AMD Radeon RX 460 GPU based Asus Dual RX460 OC edition graphics card. However, since 2019, I started using NetBSD much more regularly alongside with Manjaro Linux (which is still my primary OS) and, unfortunately, Radeon RX 460 GPU is unsupported by the former. Because of that, I decided to downgrade to an older generation hardware, so I can be comfortable in using them. After a broad research, I opted for the GIGABYTE GV-R737WF2OC-2GD which is a Radeon R7 370 based card. R7 370 uses Pitcairn Pro GPU core based on the 1st GCN architecture. The main motivation behind choosing this specific model was its similar performance to RX 460, its reasonable price and its availability in stock at local stores.

Despite some fears, the card didn't disappoint. NetBSD immediately recognized the GPU and applied proper drivers giving the expected hardware acceleration. Because of this, I started using NetBSD on my desktop quite regularly. To my surprise, it visually felt more responsive than RX 460 on Linux as well. Despite being an older model, its performance is actually at par with the replaced card in general usage, except possibly increased power usage.

Dell QLogic 57810 10G Ethernet card

Since my router supports one SFP+ 10Gbit Ethernet port, I was curious to try it out and bought the Edimax EN-9320SFP+ 10Gbit network card back in 2018. Though, being the cheapest 10Gbit solution at that time with the smallest card around, it had few annoying flaws. The card was based on Tehuti TN4010 NIC, which is poorly supported by the alternative operating systems except Windows. Any of the BSDs don't have a driver at all. Linux has one, but not in the mainline kernel. Thus, the Linux driver needs to be compiled and installed manually, and the process needs to be repeated almost after every kernel update (which happens relatively often). In the end, the Linux driver still had at least one issue - if computer goes to standby mode, NIC stops working after resume with only reboot bringing it back. Nevertheless, I was not planning to replace it, since alternatives were too expensive (especially Intel based solutions). Btw, Edimax also have never updated the driver in their page, I was using the one from github.

Unexpectedly though, one local shop offered Dell QLogic 57810 (Dell part 540-BBGS) dual port 10Gbit network card for a sizable discount. I checked that it was supported by at least FreeBSD, the Linux kernel had mainline kernel driver as well, so I took the bait and bought it. The card itself is much bigger than Edimax, having an active cooler and requires PCI-E 2.0 x8 slot instead of PCI-E 2.0 x4. On the other hand, it is a way more professional product having sophisticated firmware and two SFP+ ports. Once installed, it worked out of the box in Windows, Linux and FreeBSD, with no manual work required. Contrary to Tehuti NIC, it had no issues on resume in Linux as well. In general, I believe this purchase was pretty successful, except the fact that it is not supported by NetBSD.

I dream to port the FreeBSD driver to NetBSD, however, it may be too complicated task, since the driver is huge. Nevertheless, I am planning to make an attempt this year (sometime in 2020) and see what happens.

Dell QLogic 57810 dual SFP+ Ethernet controller

Toshiba MG04ACA600E and D-Link DGE-528T

Yet another hardware update was already extensively described in my blog. Though, the main goal was just to upgrade from 3TB hard drives to 6TB ones in my NAS server, it ended up with the bigger project from migration to Artix Linux to LVM RAID configuration on recycled 3TB drives.

The new hard drives were two identical Toshiba MG04ACA600E model drives which showed quite visible performance improvement in read operations but write speed seemingly was restricted by driver issues and showed only minimal improvement compared to older drives. Thanks to LVM RAID0 setup I also reused older 3TB drives as additional back-up storage.

Realtek RTL8169SC based D-Link DGE-528T network card was used to circumvent loss of the second Ethernet port. Together with integrated Realtek 8111C NIC it showed worse network speed over Intel based daughterboard card, but it was expected and acceptable downgrade.

Toshiba MG04ACA600E

Sanwa MA-TB41S trackball

For around ten years I was successfully using Kensington Optical Orbit trackball. It was bought in Sweden by my former colleague and friend. Initially I thought that it will stay only as an experiment, but proved to be one of the best devices I've ever used. Unfortunately, the right button started to fail so badly by the end of the last year, that I was finally forced to look for the possible alternative. Despite pretty limited trackball options, I must admit it was one of most challenging decisions on hardware selection process. The main reason for that was the lack of possibility to try them physically. I believe, there is a great risk of to buy uncomfortable trackball from the images only. It doesn't matter how much reviews you will read, there are too many factors which can affect the comfort, from your hand size to device quality and sensitivity. That is probably the reason why you can find so many contradicting opinions on the same product.

Theoretically I could even buy the same model, since Kensington is still selling it together with few other long-living models, but I wanted to find one with the scroll wheel. After long research I narrowed down the options to these three models:

• Elecom Deft Pro (M-DPT1MRBK)
• Kensington Orbit with Scroll Ring
• Sanwa Supply MA-TB41BK/S

Though, Sanwa trackball was my last choice, I ended up buying it because of difficulty to find Elecom model in Europe, and relatively bad reviews regarding the quality of Kensington trackball buttons. Unfortunately, I can't tell yet if I made a right choice... During, the first month I was really disappointed. The trackball appeared to be a bit too big for my hand, making it difficult to reach buttons comfortably. Quite often I was accidentally moving the ball before clicking mouse buttons, thus easily missing intended button or other UI element. Scroll wheel was too slow, too big and clunky. My hand was constantly getting tired. Nevertheless, I started to get used to it over the time, thus decreasing the strain of the hand and increasing precision. Though, the scroll wheel still stays as the biggest inconvenience, since it was the major feature I had been looking for. It works, but scrolling is very slow and reaction time after rotating the wheel visibly lags behind. Furthermore, my thumb gets painful and tired easily, even over the time I haven't really gotten used to it. Honestly, I am not sure, if I will keeping using it, I may switch to a regular mouse or try the Kensington Orbit trackball with the scroll ring. It is probably the most unsuccessful hardware purchase in 2019.

NetBSD

I was quite active in the NetBSD project community this year: I managed to port IC Plus IP1000/1001 PHY driver from OpenBSD (used by many VIA EPIA boards, also IC Plus own network cards), fixed support for VIA VX800 (and possibly VX855, VT8237S) SATA controller (previously partially working in IDE mode only), 4World USB to Serial adapter (already mentioned in 2018 review), found the fix for the Biostar X370GT5 SATA controller locking issue, requested to pull-up the fix for D-Link DUB1312 USB network card to NetBSD 8 release. In addition, I noticed and identified the applied fix for the long standing bug on Ryzen system, where the OS was failing to identify a second SATA hard drive. This bug was causing to stall even UEFI POST process on reboot. Fortunately, this fix made it into NetBSD 9.0 release. Also I noticed some typos and white-space issues in the code. Finally, I updated the seemingly abandoned Codelite IDE package in pkgsrc to build the latest stable version at that time (from 9.1 to 13.0). Despite these successes, I also had some let-downs. I couldn't fix the USB and Ethernet issues on eBox 3352DX3-AP computer. I found a workaround to make Ethernet controller work, in case SMP and ACPI is disabled, but the proper fix is still unclear. Besides that, once suddenly Fnatic Gear Rush keyboard stopped working, with the help of NetBSD developer I identified that it was caused by accidental switch to 6KRO mode. It appeared to be working in NKRO mode only (which was the opposite up to NetBSD 7.1 release). Hopefully, it can be fixed to work on both modes in the future. Seeing quite a successful last year, I hope that I will be able to solve some issues in 2020 as well.

eBox 3352DX3-AP 

The last chapter I will dedicate to some insights on how to run BSD system on eBox 3352DX3-AP VortexDX3 based system, since I promised that on the last review.

FreeBSD 12.0 works the best out of BSDs, which can perfectly boot on default BIOS configuration. The only issue is the integrated network controller (R6040) which fails to work. This issue is common to all BSDs, since drivers are based on FreeBSD one. Similarly to the described below workaround on NetBSD, it may be also applied for the FreeBSD. By removing all the vte_reset() calls in the driver and recompiling a custom kernel, it should make the network work. Unfortunately, the latest release at time of writing (12.1) introduced some regression which causes instant failure on boot. I submitted the bug report but I don't expect it to be resolved soon. So, in case FreeBSD is a preferred choice, I recommend to run 12.0 release. Alternatively to editing and compiling the custom kernel, USB based network controllers can be used to enable the network.

OpenBSD is probably on the worst situation. I identified only one way to boot into the system without kernel recompilation by disabling "ACPI aware OS" option in BIOS. However, neither USB nor Ethernet works, which renders the system usefulness limited to some local automatic jobs only. It can boot with ACPI enabled/IDE in legacy mode by recompiling kernel without DIAGNOSTIC option. SMP works in both cases. If you want to work with OpenBSD for any reason, I would recommend to look for the system with COM ports (or try to solder the one).

NetBSD support is somewhere in the middle among the three. In order to boot the system with "ACPI aware OS" option enabled in BIOS, IDE should be set to "legacy mode". Otherwise, various timeout exceptions will occur and system will fail to boot. Similarly to OpenBSD, neither USB nor network will work in this case but both CPU cores (SMP) will work without requirement to rebuild the kernel. Booting with ACPI and SMP disabled (boot -12) will give USB support. Furthermore, it is possible to make network work in this case as well, but removing vte_reset() calls in if_vte.c (R6040 driver) and rebuilding your custom kernel. In case loosing SMP and ACPI are acceptable options, it makes a fully working system. Unfortunately, a workaround for the network didn't work for OpenBSD (more specifically, it actually does work, but network still fails to connect due to some other issue).

Summary and 2020

2019 was a pretty good year in the hardware/software context. Most of my projects went smoothly, and newly acquired hardware met or even exceeded expectations (except the trackball). It was also the most active year in NetBSD for me. Besides starting using it as Desktop operating system quite regularly, I managed to provide several patches to improve hardware support and provided my first contribution to pkgsrc project. I hope to keep this pace in 2020 as well, though time-constraint is my main enemy. Hardware wise, I don't have specific plans for 2020. I may upgrade to a newer Ryzen CPU and upgrade some other parts but non of these are a high priority. Like last year, such decisions probably will depend on pricing and unexpected deals. I do plan to revive my Alpha CPU based Microway PC164 Screamer system and I already have bought "old new" 8x32MB modules of SIMM RAM (Samsung KMM53616000AK-6) for it. Considering all these future plans, I believe that I will write at least a few articles this year, which I hope will be an interesting read.

LVM RAID on Artix Linux

This is a follow up article to activities started with the migration from Arch Linux to Artix Linux distribution. Since the switch over to OpenRC based distribution was successful, I decided to move on with hardware changes soon after.

Motivation

The major goal was to reuse the replaced 3TB hard drives into RAID0 setup as additional backup storage, those combined capacity would match to newly acquired hard drives. I faced some challenges during implementation:

• Akiwa GHB-B05 Mini-ITX case can only physically fit two 3.5'' hard drives, and both places were already occupied by the main two hard drives.
• There are only two SATA connectors available on the Jetway JNF-76 motherboard.
• I wanted to keep using network aggregation, thus I need to have two Ethernet ports available. The motherboard has only one, though.
• If possible, I wanted to avoid additional expenses or keep them to a minimum.

The plan

To remedy the space limitation issue, I decided to place the hard drives outside instead, by reusing my external hard drive box and HDD radiator designed for 5.25'' bay for each hard drive accordingly. Both, the box and the bay provided a stable vertical position and can be placed close to the case, making it accessible to cables from inside the case. I have accumulated all the required cables throughout the years, so no additional purchases were needed.

To get additional SATA ports I was forced to replace my AD3INLANG-LF LAN expansion daughterboard with the ADPE4S-PB Marvell SATA controller (it is based on Marvell 88SE6145-TFE1controller). I was a bit reluctant about this decision, since I was facing constant boot issues in the past with it. It also needs special configuration to make it work on Linux. Moreover, the Jetway proprietary daughterboard connector makes it challenging to insert the board firmly. Finally, loosing LAN ports meant that I can't use network aggregation without additional PCI card. However, the only alternative was to buy a new PCI SATA controller with at least 3 SATA connectors, which is getting harder to find and the prices are not too attractive in my region. Additionally, it's hard to predict if such decision won't bring new problems along the way. So, I decided to go with the daughterboard exchange.

In order to keep network aggregation possible I needed to do one purchase. Since Intel PRO/1000 GT PCI network card from my stockpile is not compatible with the ADPE4S-PB daughterboard due to firmware clash, I needed to buy another one without network boot support. For that purpose I acquired the D-Link DGE-528 (Rev. C1) network card which is based on Realtek RTL8169SC NIC. It costed me around 7.5€ and kept the goal for minimal spendings.

Additionally, I reused one back plate panel containing 2xSATA to eSATA connectors with one 4-pin Molex power connector, one SATA and one eSATA to SATA cable. All of them I had in the pile of my parts.

Assembly

Initially, I made sure that I have enough power cables and I can extend them long enough outside the case, so that hard drives would stand vertically, stable and still with enough room for cables not to be stretched. Fortunately, I still had one free Molex connector, which I used to connect the back panel's power connector. It made it extremely easy to connect one of two hard drives, since both power connector and eSATA connector were redirected outside the case. However, the second one couldn't be connected in the same manner, because it needed one more power connector. Fortunately the PSU had four SATA power connectors, out of which one was long enough to go outside the case and reach the hard drive. So in the end, I had all four PSU's SATA power connectors used (1xSSD, 3xHDD) plus one Molex connector used for the back panel's power cable extension (1xHDD). The back panel also provided ability to attach one of the hard drives using eSATA to SATA cable. Since I had only one such cable, I used long SATA cable to attach the second hard drive from inside of the case.

Externally placed hard drives cabling

Once cabling was finished, I spent quite a long time to properly attach the daughterboard itself. Like in the past experience, the boot process was very unstable, but after multiple attempts I reached a quite reasonable stability with most of boot attempts successful. Unfortunately, I noticed one regression over Delock controller: attempts to read Kingston SSD temperature with hddtemp utility was causing it to fail (with the reboot required).

Cabling at the back plane

The easiest part of the assembly was attaching D-Link network card to PCI slot and cable cleanup. As expected the DGE-528 didn't clash with the daughterboard and it is well supported by Linux. Integrated SATA controller needed to be switched to IDE mode to avoid the clash as well.

Hard drives in external casing

RAID0 Configuration

The main goal was to setup two 3TB hard drives into RAID0 mode, so that they will be available as one virtual 6TB drive. This volume would match with my newly bought 6TB drives and act as yet additional backup storage. To achieve this, I tried to use Marvel firmware first, but unfortunately it was freezing up on RAID creation attempt. I couldn't figure out the reason, but it didn't seem like it was a capacity limit, since 6TB hard drives were detected by the controller without issues. Some drive incompatibility looked like more plausible explanation but I had no means to test and verify my assumptions. As a consequence, I decided to try to setup LVM managed RAID instead. Using two sources from Gentoo Linux wiki and Red Hat Linux documentation I successfully configured my LVM RAID0 by using these commands:

• Install and start LVM service:
• sudo pacman -S lvm2 lvm2-openrc
• sudo rc-update add lvm boot
• sudo /etc/init.d/lvm start
• Create LVM physical volumes and volume groups
• sudo pvcreate /dev/sda1 /dev/sdc
• sudo vgcreate nasbackupvg /dev/sda1 /dev/sdc
• sudo vgs #to check
• sudo vcreate --type raid0 -l 100%FREE -n nasbackuplv nasbackupvg
• Format and mount volume using XFS filesystem:
• sudo mkfs.xfs /dev/nasbackupvg/nasbackuplv
• sudo mkdir /mnt/raid
• sudo mount -t xfs /dev/nasbackupvg/nasbackuplv /mnt/raid
• Edit /etc/fstab by adding the line (in order to mount volume on boot):
• /dev/nasbackupvg/nasbackuplv            /mnt/raid    xfs    defaults,relatime    0    4 

Once RAID setup was ready and working, I also edited my rsync scripts to accept destination path and updated my crontab configuration to sync with the new mount point. With this step, the goal to reuse hard drives for backup was successfully achieved.

I also performed some performance metrics of all attached drives:

• sudo hdparm -tT /dev/sdX and dd if=/dev/zero of=output.img bs=8k count=256k:
• Seagate 3TB (attached to Marvell controller)
• Timing cached reads:   1000 MB in  2.00 seconds = 500.18 MB/sec
• Timing buffered disk reads: 320 MB in  3.00 seconds = 106.52 MB/sec
• 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 39.3878 s, 54.5 MB/s (for RAID setup Toshiba+Seagate)
• Toshiba 3TB (attached to Marvell controller)
• Timing cached reads:   1002 MB in  2.00 seconds = 500.75 MB/sec
• Timing buffered disk reads: 326 MB in  3.01 seconds = 108.44 MB/sec
• 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 39.3878 s, 54.5 MB/s (for RAID setup Toshiba+Seagate)
• Toshiba 6TB (both attached to VX800 controller)
• Timing cached reads:   1012 MB in  2.00 seconds = 505.75 MB/sec
• Timing buffered disk reads: 528 MB in  3.00 seconds = 175.78 MB/sec
• first HDD: 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18.6864 s, 115 MB/s
  second HDD: 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 15.9705 s, 134 MB/s
• Kingston SSD (attached to Marvell controller)
• Timing cached reads:   982 MB in  2.00 seconds = 491.40 MB/sec
• Timing buffered disk reads: 324 MB in  3.01 seconds = 107.47 MB/sec
• 2147483648 bytes (2.1 GB, 2.0 GiB) copied, 36.0755 s, 59.5 MB/s

Network aggregation

Network aggregation reconfiguration was required as well as a result of hardware changes. Instead of using AD3INLANG-LF daughterboard with three Intel 82451PI network controllers, I utilized the integrated Realtek 8111C controller and PCI attached D-Link DGE-528T network card with Realtek 8169C NIC. The integrated one was named as ens1 and the D-Link one as enp4s3, so configuration was the following:

• nmcli con delete bond0 # deleting previous interface
• nmcli con add type ifname bond0 bond.options "mode=802.3ad" 
• nmcli con add type bond ifname bond0 bond.options "mode=802.3ad" 
• nmcli con add type ethernet ifname ens1 master bond0 
• nmcli con add type ethernet ifname enp4s3 master bond0

It worked as expected but the transfer speed reduced to 40-43 MB/s compared to >50MB/s which Intel NICs were usually achieving. Regression was expected and observed in the past, acceptable for current usage scenarios.

D-Link DGE-528T

Conclusion

In general, the plan went quite successfully. I managed to reach all the goals with minimal spendings and effort. They were few issues like multiple attempts to attach daughterboard properly, Marvell firmware RAID creation failure but I managed to circumvent them in one way or another. Some performance metrics are not stellar but they are sufficient for home NAS usage at present day. Though, I believe that it is the last major hardware update around this motherboard, since I am reaching the limits with this decade old platform. The next step would require more modern solutions but by that time the current system will still serve me well.

Arrangement of PC and hard drives

Migration from Arch Linux to Artix Linux

Recently I reached the point where 3TB hard drivers were getting almost full and I needed an upgrade. As a result, I opted for two Toshiba MG04ACA600E 6TB hard drives which replaced Toshiba DT01ACA300 and Seagate Barracuda ST3000DM001 3TB models. They were successfully recognized by the Jetway JNF-76 motherboard, on which my NAS server is based on. As a matter of fact, VIA AHCI/RAID firmware always properly displays them in SATA II mode (max speed for all VIA controllers AFAIK), which wasn't the case with the previous setup when one of the drives randomly would drop to SATA I. In general, there is nothing to complain about them, hopefully they will be reliable too.

Toshiba MG04ACA600E

This upgrade and few unexpected free days made me rethink both software and hardware configurations again and come back to the original question of the Linux distribution to be used. Probably one additional kick was the news about Project Trident decision to move from FreeBSD-based TrueOS to Void Linux, which made me revisit some light-weight distributions, init systems and file systems. I was even considering to try NetBSD with OpenZFS but quite soon this plan faded away due to lack of experience on managing OpenZFS filesystem. Initial testing showed that I can easily destroy my data and before such a move, I should be really confident with it. Even though I was very much satisfied with Arch Linux setup too, I was itching to try some systemd-free distribution instead, which gives me more natural and familiar way of work. The relatively recent consolidation of Arch and Manjaro OpenRC spinoffs into Artix Linux caught my major attention for the obvious reasons. It is still based on Arch, which provides a more familiar environment, spirit and tools. The distribution officially supports OpenRC and runit init systems. I chose OpenRC one, created migration plan, and started the journey.

First boot

To make sure that it boots and recognizes my hardware, I downloaded the latest artix-base-openrc-20191009-x86_64.iso image which I could find at the time of migration in one of their mirrors. System booted without issues and recognized all the required hardware, pata_via module probably was compiled into the kernel since I didn't need to configure it separately, contrary to the Arch Linux. Setup included JFS and XFS mounting option support which was required for my data disks. It reassured me to go forward since I didn't find any potential setbacks.

The plan

To minimize a potential regression impact, I decided to prepare a transition plan. It wasn't very detailed, since it did not describe all the specific commands but it pointed out general actions I would need to perform:

• Backup /home and /etc/fstab
• Backup samba, crontab, modules and network settings.
• Boot into Artix setup and backup Arch system disk (it has dd included).
• Install Artix itself
• Install/configure required software and services: samba, wget, rsync, git, fossil, jfsutils, xfsprogs, rtorrent, lm_sensors, hdparm, hdtemp, ethtool, vim, vi, man, openssh.
• Restore /home, crontab
• Configure network
• Configure mounting points to data drives
• Install/configure powerd

Migration

The initial step was to prepare backup for all settings, /home folder and Arch Linux system disk itself. Individual settings files were simply copied manually one by one, and /home folder was synced using rsync utility. For the Linux system disk backup I booted into Artix setup and used dd utility together with gzip compression utility to copy all the system disk (dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c  > /mnt/nasbackup.img.gz). This step probably took the longest time wise, preparing compressed image of 240GB SSD drive took way longer than I was expecting (hours). Probably it was related to limited performance of the system itself.

Once all backup were ready, I moved on to the installation part. The Artix installation process was based on the steps from distribution's wiki Installation and Migration sections so I won't go much into details. It was almost smooth process except that the base installation didn't have any editor installed, and this led me to install Vim editor first before I could do any required configuration (right after chroot command). Probably the only mistake by following the documentation was the NetworkManager installation where I should have preferred Gentoo's netifrc modules with dhcpcd utility instead.

Rebooting into the newly installed system gave few more surprises on how minimal the setup was. Even quite basic applications like hostname or man were not available. Though it was easily solved by installing inetutils (for hostname) and man packages using pacman package manager, however, it still felt a bit strange, since I believe Arch base install had more software. The list of my installed packages includes:

sudo pacman -S wget rsync git fossil jfsutils xfsprogs rtorrent lm_sensors hdparm hdparm-openrc hddtemp ethtool vim vi man openssh openssh-openrc samba samba-openrc cronie cronie-openrc powerd powerd-openrc inetutils

Besides that I also installed grub, os-prober, networkmanager and networkmanager-openrc during the initial installation process. However, as mentiond above I may replace NetworkManager with netifrc modules and dhcpcd utility in the future.

As you may have noticed, all services have -openrc counterpart for OpenRC service management. OpenRC service files are installed in /etc/init.d for execution and /etc/conf.d for configuration. After that service needs to be added to a certain execution level (I used default for all) using rc-update add command and they can be started by rc-service start command. Services I have added include:

sudo rc-update add NetworkManager default

sudo rc-update add sshd default

sudo rc-update add smb default

sudo rc-update add cronie default

sudo rc-update add cpupower default 
sudo rc-update add hdparm default

The next step was to configure the network aggregation. Since I installed NetworkManager, I needed to use nmcli utility to setup bonding network interface (ensure that all interfaces are down and leases are deleted from /var/lib/NetworkManager/*.lease before proceeding):

sudo nmcli con add type bond ifname bond0 bond.options "mode=802.3ad"
sudo nmcli con add type ethernet ifname enp4s4 master bond0 
sudo nmcli con add type ethernet ifname enp4s6 master bond0
sudo nmcli con up bond-slave-enp4s4 
sudo nmcli con up bond-slave-enp4s6 
sudo rc

With dhcpcd utility it would have been a slightly different story (ensure that all interfaces are down and all leases are deleted from /var/lib/dhcpcd/*.lease before proceeding):

sudo pacman -S dhcpcd dhcpcd-openrc
sudo rc-update add dhcpcd

sudo ln -s net.lo net.bond0

vim /etc/conf.d/net
    config_enp4s4="null"
    config_enp4s6="null"
    slaves_bond0="config_enp4s4 config_enp4s6"
    config_bond0="dhcp"
    mode_bond0="802.3ad"

sudo rc

Finally, I completed my setup by restoring my home folder content, crontab and samba configuration files. Migration ended up to be easy and problem-free. With backup time excluded and ignoring some confusion during network configuration, it probably didn't take me more than few hours of work.

There are some caveats though which I noticed but I am clueless as to the cause and if it actually affects the system in any way:

• Multiple segfault messages in dmesg (not sure yet, what causes these messages but it doesn't seem to affect any of the required functionality as of result): openrc-run.sh[2008]: segfault at 8 ip 00007fdfbfb890dc sp 00007ffd4de79040 error 4 in libc-2.30.so[7fdfbfb37000+14d000]
• Warning message for bond0: "Warning: No 802.3ad response from the link partner for any adapters in the bond". This may indicate the router issue or premature warning message, but apparently the bonding interface works correctly (and router indicates it as active).

In conclusion, I can say that the OpenRC init system actually feels more intuitive and simple than systemd, but the maturity of Artix distribution is still not on par with systemd-based Arch Linux. Errors in boot messages, inconsistencies and confusing information in wiki page and even the web page itself are the signs of that. Nevertheless, for my simple NAS server requirements this distribution seems like a perfect fit and I believe I will stick with it unless stability-wise it won't prove itself. Arch Linux was very stable and polished in this regard despite its rolling release nature, I expect no less from Artix as well. If anybody would ask me for a recommendation, I would still recommend using the Arch Linux distribution, unless, that person would prefer using the systemd-free distribution for whatever reason (in that case Gentoo and Void would be a primary choice I guess). Yet, I believe Artix has a potential to become one of the strongest light-weight distributions, especially for those seeking simplicity and freedom of choice.

Planned hardware changes

Though the migration went successfully, I still have some possible hardware changes in mind. First of all, VIA based PCI controller is not compatible with the SSD I am using, which triggers a workaround in the driver to reduce transfer rate to ~60 MB/s:

ata3: Incompatible drive: enabling workaround. This slows down transfer rate to ~60 MB/s

Secondly, I am planning to reuse replaced hard drives as yet additional backup solution in RAID0 setup (which in turn will make them 6TB in total).

Because of these changes, I am considering to revert to using ADPE4S-PB SATA II daughterboard. It means checking its compatibility with Artix (hopefully the same or a similar configuration to Arch Linux will work) but I fear about the boot process stability which improved consideribly once I switched to Delock controller. However, the daughterboard can provide enough SATA interfaces for the system drive and two hard drives without hindering too much to the overall system performance (it is based on faster PCI-E interface and it supports SATA II 3 Gbit/s transfer speed). In addition to that, I will need some creativity on attaching those two additional drives, since I don't have space in mini-itx case anymore. Probably I will need to keep them outside by using some extentions to reach the hard drive SATA connectors. The main concern is that the SATA power connector is too short to go outside the case. I hold my breath on Molex to SATA adapters. For keeping them outside, I will try to reuse my old external 3.5'' HDD cases. We will see how this goes...

To keep the network aggregation I also bought a cheap D-Link DGE-528T (Rev. C1) network card with high expectations that it will successfully work with the daughterboard contrary to Intel PRO/1000 GT card, since it should not have any interfering firmware. It is based on the Realtek RTL8169SC controller, which I would pair up with the integrated Realtek RTL8111C controller. Performance-wise, I do expect some degradation compared to AD3INLANG-LF daughterboard, but this is acceptable.

D-Link DGE-528T

I am planning to write a new article if this project goes successfully.