diff options
Diffstat (limited to 'gemfeed')
| -rw-r--r-- | gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.md | 57 |
1 files changed, 56 insertions, 1 deletions
diff --git a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.md b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.md index 9d1ca40f..2e91d93d 100644 --- a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.md +++ b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.md @@ -1,6 +1,6 @@ # 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. @@ -117,6 +117,61 @@ paul@f1:/ % doas camcontrol devlist <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: + +```sh +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: + +```sh +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: + +```sh +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: |