A TrueNAS fabric cutover failed at five storage layers that each looked green from above

Both network failures had the same shape. One end of the link reported healthy and the other end was broken ^[5][9]. With no 10G driver loaded, the only interface Windows could see was the onboard Intel I219-LM 1G port, so there was nothing to bind the new address to ^[6]. The switch, to be fair to it, was right about the switch. "The physical link doesn't prove the operating system has a usable NIC," the author wrote ^[13].

The TrueNAS break had the same split. Ping and RDP to the server's new address timed out, and the workload could not enumerate its shares ^[8]. Both fixes were routine: load the correct 10G driver, then add the workload VLAN as a tagged interface on the existing LAGG with the new address on it ^[7][10]. The shares became reachable from the workload as soon as the VLAN was in place ^[10]. The author wrote down afterwards the check that catches both before cutover: layer 1 validation is "both endpoints can talk to each other at the address the change plan says they should" ^[14].

The lower three layers are the less familiar part of the list. The author separates TrueNAS's cached view of pool status from ZFS state as the kernel sees it, meaning pool importable, disks readable and labels intact. Both are separate again from the SAS and CAM path under ZFS ^[3]. That makes three components that can each give a different answer about the same disks. On the author's account, a healthy pool in the middleware does not establish that the kernel can import it. An importable pool does not establish that the disk path beneath it is sound ^[3][4].

The evidence thins out here. The supplied text ends at the first symptom past the network layer. Once the network worked, most shares appeared, but the largest one, the workload's primary storage target, returned Windows System error 67 ^[11]. The text does not describe how the middleware, ZFS and SAS failures showed up or what fixed them. The checks for layers three to five are named but not demonstrated. The author is also direct that the structure came later. "The layered framing is retrospective," they wrote. During the incident, each failure looked like its own problem ^[12][15].

I think that candour is the strongest engineering in the post. A model built after recovery is a checklist for next time. It comes from one day on one stack, and it transfers to stacks with the same component boundaries. A TrueNAS server has middleware holding its own cached pool status ^[3]. On a ZFS host without that middleware, I'd count four layers ^[16]. For a stack like this one, I'd write the cutover plan with a named sign-off per layer, each run from the side that consumes it: reachability in both directions from the host, the SMB advertisement, middleware pool status, kernel pool import and labels, and the SAS path. The author described the plan that actually ran as "a network change with a storage flavour" ^[17].