Julien LutranandClaude Opus 5
ceff4ec0d0
c8d759c claimed the ~125 Mbit/s seed rate was ks4's OVH uplink. That was
wrong, and measuring it says so: ks4 uploads at 609 Mbit/s, downloads at
900, and nas pulls 670 from OVH's network. WireGuard is not it either —
zero UdpRcvbufErrors, wg-crypt kworkers at ~2%, both hosts ~85% idle.
The limit is `data` sitting on sdb5, one 7200 rpm HGST 6 TB disk: during
the send it does 109 r/s at 14 MB/s with ~131 KB requests and a queue
depth of ~1.0, which is the random-IOPS ceiling of a single HDD reading a
fragmented 1.42 TiB dataset. 14 MB/s is ~112 Mbit/s on the wire, exactly
what we see, while the network sits idle.
Parallelism is the only lever and it works by disk queue depth, not
bandwidth: a second concurrent copy takes sdb from 14 to 21 MB/s and the
request size from 131 KB to 514 KB, lifting the tunnel from 113 to 153
Mbit/s. Recorded, along with the decision to keep the seed sequential —
one-off pass, incremental refreshes after, and incus-copy.sh is shared by
all three legs.
Also corrects the set size to the actual 1.42 TiB (~29 h, not ~31 h).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>Storage: nas
Storage + backup host on the LAN, added 2026-08.
- Always-on host. nuc is now an on-demand media box (see nuc/README.md), so everything that must stay up — LAN DNS, the HTTP proxy, torrents — lives here.
- Debian 13, Supermicro A1SAi-2750F / Intel Atom C2750 (8 c, 20 W, ECC DDR3) — build procedure: nas-install.md
- SSH:
ssh -i id_rsa_claude root@192.168.0.4 - No iGPU (Avoton is headless; video is the AST2400 BMC). Anything needing hardware transcoding stays on nuc.
- Pools:
incus— ZFS mirror across the last partition of both 120 GB SSDs; holds this host's container roots. OS itself is on mdraid RAID1 + ext4 across the same disks (rationale in nas-install.md §2).tank— the 4 TB WD Red, on direct SATA. This is the whole point of the box: the disk used to hang off a JMicron USB bridge on nuc that suspended the pool 61 times in 30 days (nuc/usb4t-dropouts.md). Single vdev, accepted — nothing on it is irreplaceable.
tank/media→/export/media: the media library. Exported read-only over NFSv4 to nuc, wherejellyfin-serverreads it; written locally only bytransmission-bt.- Backups: nuc ↔ nas cross-replication (each host's instances live on the other), plus the ks4 pull leg — nas-install.md §9, ks2/nas-seed.md.
Instances
| Name | IP | Doc | Features |
|---|---|---|---|
| blocky | 192.168.0.254 | — | unprivileged, autostart; DNS ad-blocker for the LAN. Moved from nuc 2026-08-30 so it survives nuc being powered off |
| privoxy | 192.168.0.11 | — | unprivileged, autostart; filtering HTTP proxy, listens on :3128 (not privoxy's default 8118); static config in /etc/systemd/network/eth0.network (Gateway=192.168.0.1), DNS=192.168.0.254. Moved from nuc 2026-08-30 |
| transmission-bt | 192.168.0.7 | ✅ | unprivileged, autostart; always-on WireGuard full tunnel → ks4 (egress = 193.70.35.17, kill switch: no default route in main, wg-quick's fwmark/suppress_prefixlength rules send traffic to table 51820 — netplan apply wipes those rules, so always systemctl restart wg-quick@wg0 after it); IPv6 disabled (/etc/sysctl.d/99-no-ipv6.conf) since the tunnel is AllowedIPs = 0.0.0.0/0 only and the FTTH box's native IPv6 RA bypassed the kill switch entirely. Extending the tunnel to ::/0 is not currently possible: ks4 has a global v6 address and a default v6 route but no working v6 egress (verified 2026-09-16 — both ICMP and TCP to the v6 internet fail while v4 is fine), so it cannot act as a v6 exit. Fix OVH v6 on ks4 first if v6 peers are ever wanted; /export/media disk device (shift=true), downloads to /media/downloads; web UI :9091 (LAN only). Moved from nuc 2026-08-30 |
Host tunnel
wg-ks4 — 10.8.0.22/24, peer = the wireguard container on ks4,
endpoint 193.70.35.17:51845, AllowedIPs = 10.8.0.0/24, 192.168.1.1/32.
It exists only to reach ks4's incus API at 192.168.1.1:8443 for the
05:00 pull. Key at /etc/wireguard/wg-ks4.key, unit
wg-quick@wg-ks4 (enabled).
⚠️ nas also runs a managed incusbr0 on 192.168.1.254/24 — no
uplink, nothing attached, inert. It exists purely so the ks4 replicas'
instance-level eth0 (parent: incusbr0, static 192.168.1.x) passes
validation on arrival. It must never take 192.168.1.1: that address has
to keep resolving over wg-ks4, and a local address beats a route.
Backup pools hosted here
| incus pool | dataset | receives |
|---|---|---|
nucbackup |
tank/backup/nuc |
nuc's instances (pushed nightly, 03:30) |
ks4backup |
tank/backup/ks4 |
ks4's instances (pulled over wg-ks4, 05:00; built 2026-09-16, see ks2/nas-seed.md) |
nasbackup |
tank/backup/nas |
nas's own instances (local copy, 04:00) |
nas's own instances are replicated locally rather than to nuc: nuc is
an on-demand box and usually powered off, so it is not a usable backup
target. nasbackup lives on tank, a different pool from the incus
SSD mirror the instances run on.