HOWTO: Split SSD with boot-pool to create partition for data (no USB install, easy config migration)

[sretalla]

doesn't TrueNAS use device names as well?

It may display them, but doesn't "use" them in the process of pool manipulation.

 

[TCWL]

By the way, I found a genuine use-case for using partitions as vdevs: dual actuator drives.

Q: How can I configure an Exos® 2X SATA drive in my Linux system

A: You can partition both actuators, stripe the actuators into a software RAID, or use as-is. Using the drive as-is would be a sufficient solution if you are migrating data to fill (or almost fill) the whole drive so that both actuators will be kept sufficiently busy. If you would like to treat each actuator as an individual device, then simple partitioning is an easy way to utilize Exos 2X SATA.

I was never fan of this "we don't need it, therefore it's not supported - until we need it, then it won't be supported in years because we built our software in such rigid way making changes is impossible without rewriting everything".

Yet another case of anti-pattern software development, imho.

 

[Saoshen]

I see absolutely no reason for anyone to split disks with the boot pool beyond the scientific or hobbyist interest to go beyond the limits or to explore new things.
Even if one is in need to use all the available connectors for the data etc. pools he can use available usb port(s) for the boot pool.

a great example is using micro pc's for TNS, they are typically limited internally to 1-2 disks of nvme and/or sata. sure you could use a whole disk for boot, and the 2nd disk for data, but then neither is redundant.

btw this is an example where proxmox exceeds tns, proxmox can be used and supported on a single disk for boot/data.

PS: usb boot is no longer recommended for TNS. see @ https://www.truenas.com/docs/scale/...for the,efficient replacement if issues occur.

 

[Etorix]

Probably a good advice, but doesn't TrueNAS use device names as well?

No. ZFS normally tracks pool members by UUID so drives can be reshuffled at will.

There are only so many available pcie lanes on a motherboard, putting non-critical data beside boot pool saves space (inside the case).

In case of failure, replacing a dual purpose drive is going to be a painful and convoluted excercise with the command line. You have been warned.

It is usually not that difficult to find a port which would otherwise be of little use (PCIe x1 slot? mini-PCI? internal USB?) and hook a cheap, dedicated, boot device on it, use TrueNAS as intended—and enjoy automated GUI operation.

 

[kiriak]

a great example is using micro pc's for TNS, they are typically limited internally to 1-2 disks of nvme and/or sata. sure you could use a whole disk for boot, and the 2nd disk for data, but then neither is redundant.

btw this is an example where proxmox exceeds tns, proxmox can be used and supported on a single disk for boot/data.

PS: usb boot is no longer recommended for TNS. see @ https://www.truenas.com/docs/scale/gettingstarted/scalehardwareguide/#:~:text=The recommended size for the,efficient replacement if issues occur.

I think USB flash drives are not recommended. Anyway, my boot pool is 2 mirrored nail size USB flash drives. They go fine for 2+ years now and the minimum risk is accepted by me. This risk is magnitudes less than having a split disk with data that you care about.

I use a Proxmox on a micro PC for a few services and VMs, but for my data I'd rather go by the book, so no micro PC for TN for me unless I find one with room for a mirrored pool of 2 disks and proper ECC RAM, Intel Nics etc.

 

[NugentS]

Its not really a risk using USB drives to boot from, as long as you have a regular copy of the config file available (not on the NAS). A rebuild is simple and quick. It probably takes longer to find a USB key for the ISO, copy the ISO to that key, plug it in and boot than the rebuild actually takes

 

[sretalla]

The recommendation (and system generated warning) about USB boot devices is really supposed to be directed at USB stick/Thumb drives.

Using a USB to SATA or USB to NVME bridge gives access to much more reliable flash media than is available on USB sticks, so can be relied upon for boot pool functions with very good reported reliability from the forums...

I see hundreds of posts talking about failed USB stick boot pools, almost none (maybe actually none) for USB-connected SSD/NVME boot pools (of which I personally have many also).

 

[Ericloewe]

I see hundreds of posts talking about failed USB stick boot pools, almost none (maybe actually none) for USB-connected SSD/NVME boot pools

Same here. The catch is that half the benefits of USB boot go out the window (not compact and neat, expensive). Also you need a good bridge chip, but that finally seems to be a solved problem after two decades of crap.

 

[sretalla]

The catch is that half the benefits of USB boot go out the window (not compact and neat, expensive). Also you need a good bridge chip, but that finally seems to be a solved problem after two decades of crap.

I found the relatively cheap Samsung T5/T7 portable SSDs to be a good solution... the controller and drive are hence paired well (by Samsung) and it's USB powered, so no need to run SATA power... also it's fairly small, so can be stuck to the side of a case without much trouble.

 

[Ericloewe]

Yeah, after M.2, running SATA power for a measly boot device really feels retro in all the bad ways.

 

[Stux]

Yeah, Import [a ZFS pool] vs Import [data from other filesystems]. Not great, but nobody's been able to come up with a better naming scheme over the past decade+.

Load/Unload?

Reminds me of loading disk packs on blue hardware ;)

 

[Saoshen]

mount and unmount.

about as simple and straight forward as can be.

 

[Stux]

mount and unmount.

about as simple and straight forward as can be.

Has the problem of overloading the actual "mount" that occurs on the datasets when the pool is imported, but yes, in the TN context, when you import a pool, the root dataset and all its children etc, are mounted under mnt, thus "mount" would probably be a suitable verb