Add LVM cache to existing LVM RAID1 mirror

The new HP Microserver gen8 is configured with Proxmox.

Proxmox is installed on a RAID1 LVM that runs on two uSD cards: on in the uSD card slot integrated into the motherboard, the other via a USB-to-uSD adapter in the internal USB A connector on the motherboard.
I totally forgot about it, until I realized why apt dist-upgrade was running at a snails pace.

For the rest there is little remarkable about the performance of the server. I do worry a bit about writing log records, and I did not configure any swap on the SD cards.

To alleviate the pressure on the memorycards, I add a single GB of LVM cache on SSD (on a total size of 18 GB for each of the mirrored partitions).

Steps to perform:

  • SSD partitioning
    • fdisk /dev/sdh
    • for a new/unused medium: g voor GPT partitielabel
    • n for a new partition, t for type lvm, w to write and save the configuration.
  • Earmark the partitions for LVM-usage
    • pvcreate /dev/sdh1
  • Add the physical volume to the root partition’s volume group
    • vgextend usbsdraid /dev/sdh1
  • Add the future caching device to the existing volume group
    • lvcreate -vn cache_mt_usbsdraid -l254 mt_usbsdraid /dev/sdh1
  • Convert the volume to a cached volume, indicating the caching volume
    • lvconvert --type cache --cachepool cache_mt_usbsdraid /mt_usbsdraid mt_prox_sys
  • IF THIS IS YOUR BOOT VOLUME : REGENERATE YOUR GRUB CONFIG AND IMAGE
    • I forgot about this, and had to revert the changes on the next power outage, as the system had become unbootable.

That is all. View the result by calling lvs mt_usbsdraid:

# lvs mt_usbsdraid
  LV          VG           Attr       LSize  Pool                       Origin              Data%  Meta%  Move Log Cpy%Sync Convert
  mt_prox_sys mt_usbsdraid Cwi-aoC--- 18.00g [cache_mt_usbsdraid_cpool] [mt_prox_sys_corig] 0.04   2.10            0.00     

Print this entry

Containers do have internet, Proxmox does not

I was unable to upgrade Proxmox. It turned out that internet access was lacking. More specific: the whole lan, with the exception of (the internal side of) the router was reachable. On closer inspection PBS, the backup server, had the same problem.

Reaching those servers from the router was not possible either. In the mean time the containers were accessible from the Internet, and backups were sent as usual.

After checking DNS, dynamic and static IP, bonds and bridges, ARP came in to view as the culprit. arping gave timeouts on the IPs of these servers, while arping on the hostname gave the right MAC but the wrong IP.

Cause of this all was the static ARP-entries that I set for a couple of machines, to have the MAC at hand for wake-on-lan.

De boosdoener: een statisch ARP record

After unchecking the check boxes, applying the changes and flushing the ARP table, everything started working immediately!

Print this entry

Wish list

This time around:

  • A new pillow, or at least the foamy rubber on the inside, for my bike;
  • An Ars Technica subscription, with NFC security key;
  • A comfortable and handy back pack, with multiple compartments, one opening from the top and one opening from the middle or the bottom, with padded hip belt;
  • A vacuum robot?
  • sure there is more…?

Print this entry

LVM extend, and grow ext4 file system

First run in test mode (-t)

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm --dry-run --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Skipping filesystem check for device "/dev/mapper/data-linh" as the filesystem is mounted on /home/linh
/sbin/fsadm failed: 3
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592

Notice ‘/sbin/fsadm failed: 3’, because of a mounted file system. Unmount it:

root@linhovo:~# umount /home/linh

Now run vgextend without -t, to actually have the logical volume and the file system resized:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm --dry-run --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-linh
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592
root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -vrL +30G
Executing: /sbin/fsadm --verbose check /dev/data/linh
fsadm: "ext4" filesystem found on "/dev/mapper/data-linh".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-linh
fsck from util-linux 2.33.1
linh: 74099/16752640 files (5.8% non-contiguous), 63802054/66998272 blocks
Archiving volume group "data" metadata (seqno 4).
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Loading table for data-linh (254:3). Suspending data-linh (254:3) with device flush Resuming data-linh (254:3). Creating volume group backup "/etc/lvm/backup/data" (seqno 5). Logical volume data/linh successfully resized. Executing: /sbin/fsadm --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 306637176832 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-linh 74862592
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-linh to 74862592 (4k) blocks.
The filesystem on /dev/mapper/data-linh is now 74862592 (4k) blocks long.

Check that the space is added. Some part of the system is smart enough to translate the mount point of the unmounted partition to the right partition:

root@linhovo:~# df -h /home/linh
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/data-home 58G 17G 39G 31% /home

UPDATE: I was quite surprised the free space for the file system was found even when not mounted. Upon rereading, I notice that it actually is not the case. The amount of free space matched my expectations, so I glanced over the details.

What actually is shown, is df for the partition on which the mount point /home/linh resides.

Print this entry

Adding X-Clacks-Overhead

For a long time on my to-do list, but postponed due to perceived complexity: adding X-Clacks-Overhead.

Now I got around to looking into what is actually involved, and… It’s not all that convoluted. For nginX it a single line to be added in a server, location or http block.

add_header X-Clacks-Overhead "GNU Terry Pratchett" always;

Next up was finding the right file in the Yunohost setup of nginX: I did find a single (default) sites-available, but no sites-enabled.

All configuration is put in the conf-directories, where I put the additional header in the conf of the main site in the server section.

vi /etc/nginx/conf.d/mysite.tld.conf

Now first see that the header is not there before reloading nginX:

~# curl -IL mysite.tld
 HTTP/1.1 302 Moved Temporarily
 Server: nginx
 Date: Sat, 28 Dec 2019 11:23:13 GMT
 Content-Type: text/html
 Content-Length: 154
 Connection: keep-alive
 X-SSO-WAT: You've just been SSOed
 Location: https://mysite.tld/yunohost/sso/?r=aHR0cHM6Ly9zYW55aS5ubC8=

See? No X-Clacks header. Reload nginX…

service nginx reload 

… and have a look at the headers again:

~# curl -IL mysite.tld
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 28 Dec 2019 11:25:52 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
X-SSO-WAT: You've just been SSOed
Location: https://mysite.tld/yunohost/sso/?r=aHR0cHM6Ly9zYW55aS5ubC8=
X-Clacks-Overhead: GNU Terry Pratchett

It now shows at the bottom line.

Actually the X-Clacks-Overhead is only added to the HTTP 1.1 headers. The HTTP 2 headers omit the header at the moment. After rereading the config, I added the header to the server listening at port 80 over HTTP 1.1; it gets forwarded to port 443 over HTTP 2. That block did not have the header. After adding the header there as well, the HTTP 2 headers show the X-Clacks-Overhead as well:

~# curl -IL mysite.tld
 HTTP/2 404 
 server: nginx
 date: Sat, 28 Dec 2019 11:33:18 GMT
 content-type: text/html
 content-length: 162
 x-sso-wat: You've just been SSOed
 set-cookie: SSOwAuthRedirect=;; Path=/yunohost/sso/; Expires=Thu, 01 Jan 1970 00:00:00 UTC; Secure; HttpOnly; SameSite=Lax ;;
 strict-transport-security: max-age=63072000; includeSubDomains; preload
 content-security-policy: upgrade-insecure-requests
 content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'
 x-content-type-options: nosniff
 x-xss-protection: 1; mode=block
 x-download-options: noopen
 x-permitted-cross-domain-policies: none
 x-frame-options: SAMEORIGIN
 x-clacks-overhead: GNU Terry Pratchett

One difference between the two header blocks, is that the HTTP1.1 block is capitalized, whereas the HTTP2 block is not. Fine with me 🙂

So, two points of my mental to-do list, one for the Clacks itself and one for moving it from a mental to-do list to a physical (of some sort) to-do list.

Print this entry

Wireless floor heating thermostat

We installed infrared floor heating film. It has not yet been connected, lacking a thermostat. My idea from the start was to use Arduino or compatible to build the thermostat myself. There were some reasons for that: it was cheaper than a ready built device, more flexible and an excellent reason to get started with Arduino.

So, to prevent any misunderstandings: although the floor is not wired yet, it is not wireless. The thermostat will be wireless on one end, the end to the user interface. From the thermostat to the floor it wires all the way down.

In the mean time the parts have arrived:

  • ESP32, the brains of each thermostat
  • Relays, to actually switch on or off the infra red film
  • 10k NTC’s are already under the floor, together with the film itself

The separate functions I need/want to integrate are easily found, and integrating them went quite quickly at first. The result was almost what I needed, lacking only the sensor for ambient temperature. And it only would work in the wrong order. Which functions are they and what went wrong in the first iteration?

  • Temperature measurement
  • Thermostat setting
    • On the one hand ambient temperature: the temperature we find comfortable in the room
    • On the other hand the floor temperature: the floor temperature is not allowed to raise above 29 degrees Celsius
  • Switching a relay based on measured temperature and thermostat setting
  • Accessible via WiFi on the internal domotica network

As stated, each separate function got its examples for Arduino as well as, fewer, for ESP32. I ended up with a loop that:

  • Connect to WiFi
  • Shows a web interface to turn on or off the relay
  • Measures the temperature on pushing the on or off button
  • Actually switching on or off based on measured floor temperature

So the thermostat would not interfere with the relay until a button was pressed. The loop should work in reverse order:

  • Check relay state
    • if off, measure ambient temperature and compare to thermostat value
    • if on, measure floor temperature and compare to set maximum temperature
  • Depending on above, switch the relay state or keep as is
  • Connect to WiFi for a minute
  • Show the web interface
  • Allow the thermostat to be set
  • Return to above

The next step is to have a domotica server serving the thermostat interface, and the ESP querying the domotica server every now and again for changes. That way, less time is spent broadcasting a web interface via WiFi, improving power efficiency and security. At first it will be a stand alone setup though.

Pins

What connections/pins do I need? Which pins are they on the board?

  • Ralay; the relay needs three pins:
    • Ground;
    • VCC, the relay needs 5V, but it sits on a PCB with additional logic to let it switch with 3.3V supplied;
    • Switching signal, 3.3V as well; that also drives the process towards the “floor is to hot”- or the “room is not warm enough”-branch.
    • I’m free to use any digital-out pin for this
  • Floor sensor; the floor sensor needs three pins as well:
    • Ground;
    • VCC, any, as long as it is known and constant. I’ll use 3.3V as supplied by the ESP32;
    • Sensor pin;
    • The sensor-pin; any analog-read pin will do. It will read the voltage ‘halfway’ the ground-NTC-sensor-resistor-VCC series. The read voltage is then converted to a temperature.
  • Ambient sensor; just like the floor sensor:
    • Ground;
    • VCC;
    • Sensor pin / analog read.

I have some trouble converting the pin-examples I find on the Net to the actual pins on my ESP32. The names of the pins in those pictures are just a few letters different from the names of the pins silkscreened on the PCB. The pins that are supposed to be called ‘sensor VP’ and ‘sensor VN’, are called ‘SP’ and ‘SN’, and are moved one pin because I got an extra 3.3V pin on one side and extra GND pin on the other side.

Most of the pins are called Gnn, with nn being a number ranging from 0 to 36, in seemingly random order. G0 is between G2 and G4, and then G17 and G16 come before G5. G could stand for GPIO, and sometimes they match the notation on the images I find online. Of course not all options for each pin can be silkscreened on the tiny PCB. With my currently limited knowledge of Arduino programming, it does not help understanding the code I find in the wild. How should I assign a name to an input or output? Lets just try it with simple programs, building and understanding from there instead of hacking something together and hoping for the best: there is no lack of basic tutorials, it just takes some time to apply them to my ESP32-board, test its behaviour and measure electric properties of pins.

Test with ‘touch’ pin

While reading up on the pins and how to interact with them, I come across an explanation of ‘touch’ pins. They presumably can be used as input by just touching them. I’ll make sure to test that and keep it in mind as another way of setting the temperature.

Actually writing a simple program myself has taught me more than reading five of them and then flinging together something complicated to see what sticks. Namely:

  • Arduino is touchy about casing. Be sure to write analogRead, not analogread or Analogread: it won’t be recognized.
  • Same goes for semicolons. Forget one, and the compiler complains that there is an unexpected } instead of a ;
  • Prototyping is fast once you got something you understand that is working.
  • Use the right function for the type of input you’re working with. In case of the touch pins:
    • My first guess was using analogRead. It ‘works’, giving 12 bit high values (4095) when licking the connected wire or touching either the 3.3V or the 5V pin, 0 when connecting with GND. Using my fingers, the most intuitive way to interact with touch interfaces, gives fluctuating readings. Above 2000 when I draw blood with the pin, slowly descending values when I let go of it. Conclusion so far: it might work, but only when using more than one button and reading all of them to infer which one actually has been touched (and educating users not to touch more than one button at a time).
    • Next up was digitalRead. That gave 1 instead of 4095, 0 just as analogRead, and random 1 or 0 in between.
    • The actual function to use for touch pins is touchRead. It gives quite low (10+/-10) readings when touching the pin, and around 60 when not touching. Surprisingly, it gives 1 when touching 3.3V and 0 for GND,
    • The wire tastes as if there is some current on the line, my multimeter gives 0.7V as the amount between ground and GPIO4/T0 on the one hand and 0.6V between GPIO4/T0 and 3.3V. From GPIO4/T0 to 5V gives 2.1V, so there is some more logic involved somewhere behind GPIO4/T0.
  • Pins can be assigned in the header, above ‘void setup()’, using four indicators:
    • Type, for example ‘int’;
    • Name of the variable for the pin, for example ‘touch_pin’
    • Assignment using the equal sign (=);
    • GPIO number, just ‘4’ in this case;
    • Don’t forget the semicolon!
    • The whole assignment looks like: int touch_pin = 4
    • While reading: touchRead (touch_pin)
  • Pins can be read inline without assigning a variable as well: just write the number of the GPIO on the spot where it is needed:
    • touchRead (4)
  • Arduino is not touchy about spaces between brackets and letters. A space “touchRead ( 4 )” gives the same result as no space “touchRead(4)”.

For future reference, the file with the code is attached.

Print this entry

Fritz!Box configuration editing – as text

AVM offers a friendly user interface with Fritz!OS for their Fritz!Box’es to unleash a nice range of features. Many things are possible, though some things take quite a few clicks.

One of the things that take many clicks, is arranging port fortwarding for hosts on the LAN.

The easiest way, after a fashion, is to make a backup of the configuration, make changes and import the file again. The difficulty here is that the file is checksummed, and Fritz refuses to read the configuration.

While the ages, solutions have been written in various languages. I use a python script, fritzchecksum, written by Mementum/DRe.

It is an pip-installable module, pip install fritzchecksum, takes a Fritz-file as input and returns the old and new checksum for easy search and replace. The program supports automatic editing of the file as well, I have always replaced by hand.

For future reference, the zip contains the current download from github. Should not be necessary to download it here, but you never know!

Print this entry

Open vSwitch on Proxmox

Since Open vSwitch (ovs) and Linux bridging can’t mix, it is advised to switch to ovs before creating a whole lot of bridges.

# apt install openvswitch-switch

In networking of the node, I deleted vmbr0 of type=linux bridge, and added a new bridge vmbr0 of type ovs bridge. Proxmox likes to reboot after that, perhaps a restart of networking had been enough. Only restarting openvswitch-switch was not enough.

A presentation on an Open vSwitch conference suggested to edit two files:

  • /etc/default/lxc-net
    • set USE_LXC_BRIDGE=”false”
  • /etc/lxc/default.conf
    • set lxc.net.0.link = ovsbr1 ; would be vmbr0 in my case

The first is already set in /etc/default/lxc. The file lxc-net does not exist (though it is referenced in the lxc file).

The second file is almost empty, it has only the line ‘lxc.net.0.type = empty’.

Adding a new container uses vmbr0 by default; now I don’t know whether that is because I named the new bridge the same as the old one, or because OVS is being used by default.

Anyway: the container asked for a DHCP lease and received it from the router.

Print this entry

Proxmox first impressions

Once rebooted after installation I visited the IP of the server at port 8006. Unable to connect. Now what?

SSH does answer, a quick search for ‘proxmox installation complete no answer on 8006’ turned up someone without pve-manager installed. I did have it installed, but did not see proxmox repositories in /etc/apt/sources.list.

Servethehome has a checklist for proxmox 6, I took the pve-no-subscribtion repository from there:

deb http://download.proxmox.com/debian buster pve-no-subscription

Apt update complains about missing keys for jessie. Not a problem for my installation as such, but might break something that does not expect warnings (even a simple apt update && apt upgrade -y will halt), so add the key:

# wget http://download.proxmox.com/debian/key.asc
http://download.proxmox.com/debian/key.asc
Resolving download.proxmox.com (download.proxmox.com)... 2a01:7e0:0:424::249, 212.224.123.70
Connecting to download.proxmox.com (download.proxmox.com)|2a01:7e0:0:424::249|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1703 (1.7K) [application/octet-stream]
Saving to: ‘key.asc’
key.asc 100%[===========================>] 1.66K --.-KB/s in 0s
# apt-key add key.asc
OK

Retrying the web interface. Still no go: “the connection was reset”. Hmm… That is no ‘not found’, should I perhaps take the trouble of manually pointing at the https-protocol? Yes, that did it, add https:// in front of the IP and log in.

Shiny interface, just like in the screenshots 🙂

The summary view in the second-level tree-menu will stay active while clicking through the first-level tree-menu on the left hand, with the datacenter and node list. It shows different statistics and in a different representation (meters or graphs), depending on the subject, which is helpful in recognizing and remembering what I am looking at.

I now realize that I do have close to 30GB of space for the basic install (my 15GB * 2 for copies = 2), but no separate partition for /var. I’ll let it be, keep an eye on the level of free space and add space when needed. Reinstalling based on Debian Buster is well-documented, but with no experience with proxmox I’ll keep the installation close to default.

To see how much of the assigned space is used in which way, I compared the different views and some relations are not directly clear to me. I expected around 30GB at some level, and 15GB at another. What I actually see, is:

  • Bare sectors, fdisk: 61863937 * 512 ~ 29,5 GB
  • At ‘datacenter’ level: 2.2GB of 54.0GB used
  • At node level: 2.2GB of 28.0GB used
  • Two storage objects:
    • local: 2.2GB of 28.0GB used
    • local-ZFS: 0 of 25.8GB used

I can see the relation between 28 and 54, and between 28 and 25.8, but not between 54GB on the datacenter and 29.5GB actual usage on disk.

After defining ‘copies = 2’, I had expected all downstream values to be half of what I see here. Some thinking further: is the read value of fdisk is inside the node, not on the actual hardware? Then I would not see the total size of the SSD. I posted a question on the proxmox-forum, awaiting moderation and a reaction.

Print this entry

Proxmox

Once I decided on visualization and settled on Proxmox as the host platform for the new NAS, I stranded in decisions to make with regard to the installation.

The first problem was the installation medium itself: I wrote the installer to a uSD card, put it in an adapter to regular SD, that into SD2USB and finally in the USB3 port of the NAS.

Booting OK, installer menu OK, but starting the installer: not OK.

I tried a few times, but the image seemed broken. The kernel would halt somewhere between loading the initial ramdisk and actually starting the installer.

I checked the SHA256-checksum, reflashed on another memory card, used another SD-card-reader: all to no avail. In the end I started trying other USB ports; not just USB3 in front, but first USB3 on the back, and in the end USB2 on the backside.

That worked. The card readers are USB3, but maybe the uSD cards get upset at some point. Anyway, on to the installation.

Target harddisk: SSD or HDD? Which file system? Am I happy with automatic partitioning?

System disk: SSD. I want to be able to spin down as many HDD’s as soon as possible, as long as possible. If I start building the system on one of the spinning disks, it is more difficult to replace it in the future and am I stuck with it. Besides that, the base system should take only tens of GB’s, so there is enough space left for caching, swap and other things that also benefit from increased I/O.

Which file system? As long as I can remember, I have used LVM, the last ten years in combination with EXT4 on a md-stacks. It is very flexible and offers live resizing of nearly anything.

Proxmox does not do LVM out of the box, but it does offer ZFS (ZoL, ZFS on Linux). I have been postponing ZFS usage for a couple of years now, and am still hesitant to take the plunge. How many disks? How many pools? What size? Shit, non-ECC-RAM; and how about mirrors with differently sized disks? What about TRIM on the SSD?

I started reading about ZFS on a single device pool, retraced my steps and considered a pool with SSD and spinning disk mirrored. I found one viable option is to combine the 1TB spinning disk with the SSD for some reasons:

  • It is the only non-SMR-disk I have available at the moment;
  • It is similar in size to the 1TB SSD;
  • I am not committed to keeping either the 4TB disk or the 6TB disk in the machine:
    • I might take one or the other out and use it in a USB case for external back up
    • I might swap either for a disk the size of the other, to create another mirrored set.

I hope that the pool will be smart enough not to spin up the HDD for read, that would nullify the benefit of the non-spinning SSD. If that is the case, I’ll investigate how to make a single device pool out of it.

The other option is running the pool on a single device with copies = 2; I’d use double the space, but there is no spinning disk involved.

Then there’s the question of partitioning. Just the root partition could do with some 10GB. I’d put at least /var on a separate partition, so that log files and temporary files don’t cause / to fill to 100%, some 3GB. ZFS copies = 2 means some 30GB. With swap equal to RAM is another 32GB, and then a couple of GB for ZFS ZIL. That leaves roughly 900GB of unpartitoned space.

It is all a bit theoretical up front; I hesitate to just take the defaults and see down the road. Those times I did that, I regretted it later on. Now in particular, with the quad-level flash disk and less than 400 rewrites per cell (360, according to Samsung), I prefer not to start on the wrong footing. Anyway, it can’t be helped so I just have to bite the bullet. All things considered, I take the SSD-only way for the initial installation.

Phew, that took just four nights to get through the first screen of the installer!

That was the single choice to make then; from there to installation complete and reboot took about five minutes.

Print this entry