Filesystem adventures

So as last academic year of high school came to a close in 2020, I was given the luxury of spare time before I would take up University. My little essential device that got me through classes was my trusty Chromebook. I had at times when it was less essential, explored dual booting on it (first with John Lewis’ SeaBIOS payload, before switching over to the version maintained by MrChromebox). I had also dabbled in running desktop Linux with Crouton, and when it became available, I installed Crostini, the official way to run Linux applications under ChromeOS. However, when school was in full swing, I did not want to risk the possibility of potentially making my main Essay writing device non-functional. So in giving with my long term mission to de-Googlify, I decided to install Arch Linux as the machine’s main OS. With some flair of course. I am not new to Arch Linux, having now used it now as my daily driver operating system for quite a few years (with spells of swiching to Manjaro) after much Distro hopping and experimentation. I have experience with setting up slightly more complicated Grub/initramfs/boot set ups before. Such as installing 2 different distros to the same file system (utilizing btrfs’s subvolume functionality). It took me a while to set up properly, but I’ve set up encrypted LUKs block devices a couple times. My goal three primary goals with this project were: Improve performance. To be achieved through increasing storage speeds including of a larger and faster swap space (as I was a bit of ChromeOS power user who has too many tabs open at one time, I may have not only maxed out the 4GB of DDR3 RAM but also the 5GB dedicated to Swap) Try new technologies and gain more practice in implementation. (There is only so much one can learn from reading pages on the Arch Wiki, it is sometimes better to use the software yourself to test out how it behaves in the real world. I got experience with new software, more on that later) To have a new low power server (though this goal was replaced with different ambitions, with will be a subject to a different post)

To clarify, the model of Chromebook that I had was an Acer Chromebook R11. 32GB eMMC, 1x USB 3.0, 1x USB 2.0, M.2 slot (type E) housing an Intel WiFi AC card, 1x full sized SD card slot, 1x HDMI. Powered by a Celeron N3150 fed with 4GB of DDR3. As 32GB of eMMC is not much to go around for a laptop, even a Chromebook, soon after getting the laptop, I purchased a 32GB SD card to live permanently in the SD card slot. It ended up being mostly used for storing large PDF files and when I chrooting with Crouton, I used it as storage. So one design decision was that I wanted to RAID 0 both of the drives together. If one of them were to fail, oh well, that was a fun holiday project but nothing of value was lost.  So I had really 3 choices to choice from: btrfs, ZFS, or mdadm (aka, the kernel’s built in RAID). I really wanted to use btrfs as at the time I did not have much experience with it. It would not work in my usecase for a couple reasons: First, even though swapfile are supported, it is only supported for single drive volumes. Second, I wanted to encrypt the files so that raises the issue of where to put that layer (I could either have put Luks under btrfs, but that would be inefficient as the kernel would need to encrypt different parts of a write differently. Unlocking 2 different Luks partitions are possible at boot time using crypt tab and such but that would make a lot of things more complicated and a greater headache to manage. Alternativily I could put the encryption on the filesystem level, which albeit not as private could have functioned. Though not as simply as a simple Luks block device). Next up, ZFS. Due to all the licencing issues that surround the OpenZFS project, Arch does not provide its kernels or install ISOs with ZFS support. I did not want to jump through the extra hoops with this project. Also, ZFS has a reputation of using up as much RAM as possible, which goes counter to wanting to optimize system resource usage. That left good old kernel provided software RAID as the most viable candidate. (though if I would do it again, I would have a go at using ZFS which does support many of my requirements in only one block device) So to recap so far, I have 32GB of eMMC (which is essentially a soldiered on SD card) and 32GB of my SD card which have a RAID 0 array on them. As the SD card actually was slightly larger (I think that was because of the larger number of writes that the eMMC had endured but I’m not certain on that point) I put the EFI partition on the SD card (oh I forgot to mention, I set up the system with an encrypted /boot though I am aware it does not massively add to security) On top of the RAID block device I set up a Luks partition (Luks1 format due to encrypted /boot. Or to put another way, the main Grub binary first mounts the root file system, finds it’s config, then loads Linux that’s located on that filesystem. Without an encrypted /boot, Grub does not need to touch any encrypted file systems but that does leave your kernel, initramfs, and Grub config unencrypted) On top of the Luks device, I decided to put an LVM volume. In hindsight, I could of just gotten away with a swap file instead of a swap partition, but I did not have experience with LVM volumes so I thought I’d give it a try. The LVM volume was split into 2 logical volumes, one for swap (your standard mkswap partition) and the other for my root file system. I decidied for this install to try out XFS as I read it has better performance in some areas (though in hindsight, whatever filesystem I would choose would not make much of a difference). So I had Arch installed on XFS, on LVM, on LUKs, on RAID. Now the hard part was to get point the kernel to where the root filesystem was located (which was possible by synthesizing multiple guides on the Arch wiki page). Now for the userspace side of the install: