In SCALE 25.10.2.1, I’m in the process of migrating from a mirror pool to a Z2 pool. As part of this process, I created a fake disk in the form of a loopback device, after which I created a 4-disk Z2 pool that included the fake disk, and then I offlined the fake disk and sent the pool into a degraded state. All of this had to be done at the command line. I then imported the pool into the GUI, and I’m in the process of replicating datasets from the old mirror to the new Z2 pool. The replication is of 7 TB of data so is taking a while. Once the replication is completed, I’m going to destroy the old mirror pool and add the disk from it to the Z2 pool, which will move it out of a degraded state.
The one snag in all this is that, when I created the Z2 pool at the command line, I mistakenly used the Linux disk designation (/dev/sdX, e.g. /dev/sdb) rather than unique ID to specify the disks in the pool. After I imported the Z2 pool into the GUI, the disks in the pool still have this /dev/sdX designation. This is a problem because if I ever switch SATA ports, which could happen when I’m doing maintenance in the case, Truenas could lose track of the disks in the pool, at least as I understand it.
So here is my question. I’ve read elsewhere that the best way to fix this problem is to export the pool from the GUI, then at the CLI, import the pool using “zpool import -d /dev/disk/by-id [POOL_NAME]”. I might then need to import it again in the GUI, after which the pool disks should have unique ID designation. I am tentatively planning to do this once the replication has completed.
Does this sound like it would work and would be a good way to solve the problem?