From ae00cae4798535519de0d9c5d04537a706c3d3d8 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Tue, 27 Jan 2026 09:51:56 +0200 Subject: Update content for html --- ...5-07-14-f3s-kubernetes-with-freebsd-part-6.html | 66 +++++++++++++++++++- gemfeed/atom.xml | 70 +++++++++++++++++++++- 2 files changed, 132 insertions(+), 4 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html index 3df72356..879219f4 100644 --- a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html +++ b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html @@ -13,7 +13,7 @@

f3s: Kubernetes with FreeBSD - Part 6: Storage



-Published at 2025-07-13T16:44:29+03:00, last updated: 04.01.2026
+Published at 2025-07-13T16:44:29+03:00, last updated: 27.01.2026

This is the sixth blog post about the f3s series for self-hosting demands in a home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution used on FreeBSD-based physical machines.

@@ -139,6 +139,70 @@ http://www.gnu.org/software/src-highlite --> <CT1000BX500SSD1 M6CR072> at scbus1 target 0 lun 0 (pass1,ada1)
+Update: 27.01.2026
+
+I have since replaced the 1TB drives with 4TB drives for more storage capacity. The upgrade procedure was different for each node:
+
+**Upgrading f1 (simpler approach):**
+
+Since f1 is the replication sink, the upgrade was straightforward:
+
+1. Physically replaced the 1TB drive with the 4TB drive
+2. Re-setup the drive as described earlier in this blog post
+3. Re-replicated all data from f0 to f1 via zrepl
+4. Reloaded the encryption keys as described in this blog post
+5. Set the mount point again for the encrypted dataset, explicitly as read-only (since f1 is the replication sink)
+
+**Upgrading f0 (using ZFS resilvering):**
+
+For f0, which is the primary storage node, I used ZFS resilvering to avoid data loss:
+
+1. Plugged the new 4TB drive into an external USB SSD drive reader
+2. Attached the 4TB drive to the zdata pool for resilvering
+3. Once resilvering completed, detached the 1TB drive from the zdata pool
+4. Shutdown f0 and physically replaced the internal drive
+5. Booted with the new drive in place
+6. Expanded the pool to use the full 4TB capacity:
+
+ +
paul@f0:~ % doas zpool online -e /dev/ada1
+
+
+7. Reloaded the encryption keys as described in this blog post
+8. Set the mount point again for the encrypted dataset
+
+This was a one-time effort on both nodes - after a reboot, everything was remembered and came up normally. Here are the updated outputs:
+
+ +
paul@f0:~ % doas zpool list
+NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
+zdata  3.63T   677G  2.97T        -         -     3%    18%  1.00x    ONLINE  -
+zroot   472G  68.4G   404G        -         -    13%    14%  1.00x    ONLINE  -
+
+paul@f0:~ % doas camcontrol devlist
+<512GB SSD D910R170>               at scbus0 target 0 lun 0 (pass0,ada0)
+<SD Ultra 3D 4TB 530500WD>         at scbus1 target 0 lun 0 (pass1,ada1)
+<Generic Flash Disk 8.07>          at scbus2 target 0 lun 0 (da0,pass2)
+
+
+We're still using different SSD models on f1 (WD Blue SA510 4TB) to avoid simultaneous failures:
+
+ +
paul@f1:~ % doas camcontrol devlist
+<512GB SSD D910R170>               at scbus0 target 0 lun 0 (pass0,ada0)
+<WD Blue SA510 2.5 4TB 530500WD>   at scbus1 target 0 lun 0 (pass1,ada1)
+<Generic Flash Disk 8.07>          at scbus2 target 0 lun 0 (da0,pass2)
+
+

ZFS encryption keys



ZFS native encryption requires encryption keys to unlock datasets. We need a secure method to store these keys that balances security with operational needs:
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 14c0f6a0..bf41e311 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2026-01-24T23:12:38+02:00 + 2026-01-27T09:50:13+02:00 foo.zone feed To be in the .zone! @@ -6449,7 +6449,7 @@ content = "{CODE}" f3s: Kubernetes with FreeBSD - Part 6: Storage https://foo.zone/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html - 2025-07-13T16:44:29+03:00, last updated: 04.01.2026 + 2025-07-13T16:44:29+03:00, last updated: 27.01.2026 Paul Buetow aka snonux paul@dev.buetow.org @@ -6459,7 +6459,7 @@ content = "{CODE}"

f3s: Kubernetes with FreeBSD - Part 6: Storage



-Published at 2025-07-13T16:44:29+03:00, last updated: 04.01.2026
+Published at 2025-07-13T16:44:29+03:00, last updated: 27.01.2026

This is the sixth blog post about the f3s series for self-hosting demands in a home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution used on FreeBSD-based physical machines.

@@ -6585,6 +6585,70 @@ http://www.gnu.org/software/src-highlite --> <CT1000BX500SSD1 M6CR072> at scbus1 target 0 lun 0 (pass1,ada1)
+Update: 27.01.2026
+
+I have since replaced the 1TB drives with 4TB drives for more storage capacity. The upgrade procedure was different for each node:
+
+**Upgrading f1 (simpler approach):**
+
+Since f1 is the replication sink, the upgrade was straightforward:
+
+1. Physically replaced the 1TB drive with the 4TB drive
+2. Re-setup the drive as described earlier in this blog post
+3. Re-replicated all data from f0 to f1 via zrepl
+4. Reloaded the encryption keys as described in this blog post
+5. Set the mount point again for the encrypted dataset, explicitly as read-only (since f1 is the replication sink)
+
+**Upgrading f0 (using ZFS resilvering):**
+
+For f0, which is the primary storage node, I used ZFS resilvering to avoid data loss:
+
+1. Plugged the new 4TB drive into an external USB SSD drive reader
+2. Attached the 4TB drive to the zdata pool for resilvering
+3. Once resilvering completed, detached the 1TB drive from the zdata pool
+4. Shutdown f0 and physically replaced the internal drive
+5. Booted with the new drive in place
+6. Expanded the pool to use the full 4TB capacity:
+
+ +
paul@f0:~ % doas zpool online -e /dev/ada1
+
+
+7. Reloaded the encryption keys as described in this blog post
+8. Set the mount point again for the encrypted dataset
+
+This was a one-time effort on both nodes - after a reboot, everything was remembered and came up normally. Here are the updated outputs:
+
+ +
paul@f0:~ % doas zpool list
+NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
+zdata  3.63T   677G  2.97T        -         -     3%    18%  1.00x    ONLINE  -
+zroot   472G  68.4G   404G        -         -    13%    14%  1.00x    ONLINE  -
+
+paul@f0:~ % doas camcontrol devlist
+<512GB SSD D910R170>               at scbus0 target 0 lun 0 (pass0,ada0)
+<SD Ultra 3D 4TB 530500WD>         at scbus1 target 0 lun 0 (pass1,ada1)
+<Generic Flash Disk 8.07>          at scbus2 target 0 lun 0 (da0,pass2)
+
+
+We're still using different SSD models on f1 (WD Blue SA510 4TB) to avoid simultaneous failures:
+
+ +
paul@f1:~ % doas camcontrol devlist
+<512GB SSD D910R170>               at scbus0 target 0 lun 0 (pass0,ada0)
+<WD Blue SA510 2.5 4TB 530500WD>   at scbus1 target 0 lun 0 (pass1,ada1)
+<Generic Flash Disk 8.07>          at scbus2 target 0 lun 0 (da0,pass2)
+
+

ZFS encryption keys



ZFS native encryption requires encryption keys to unlock datasets. We need a secure method to store these keys that balances security with operational needs:
-- cgit v1.2.3