A few questions and thank you in advance....

First ever Unraid build and I am just about to install some HDDs into the case before first boot. In my mind the hardware map goes like this.... Unraid and all dockers/apps installed to a single SSD for booting up and loading into RAM, then the OS loads up the two parity HDDs and the two cache pool SSDs... after that the main array is accessed and ready for usage. I'm guessing this "map" in my mind is not correct though.

I understand a recent(ish) update now allows Unraid to be "installed" to an HDD/SSD vs using a USB stick. Is this correct? Do I need to boot to Unraid from USB first and then "copy" the OS to the HDD of choice? Does that HDD become useless for anything else?

I'm sorry if the terms aren't fully correct as it's been several months since I dug into Unraid while I obtained the hardware I needed. I'll be using two mechanical 28TB SATA HDDs as parity drives and of course the remaining spinning disks (mix of 26TB down to 12TB drives) for the main array.

That said, I'd like to install Unraid to an SSD. I have a 1TB SATA SSD that I suspect will be wasteful to use for my Unraid OS and dockers. I have several older SATA SSDs to choose from for this from 64GB up to the 1TB option. I was planning on using 2 matched SSDs as a multi-device cache pool for redundancy. I also have a couple of NVME drives around, but since my motherboard is 4th Gen Haswell I'd have to add a PCI-E Gen 3 adapter to use them.

Finally, I'd like to add one drive at at time to the main array to ensure stability....or would it be best to just load up the case and go from there??

Once again, thank you for any advice or information.

I appreciate that video, thank you. That helped a lot.

One thing I'm still not clear on though. If I go the internal boot direction. Is there any reason I should not use the remaining space on the SSD as a cache pool?

4 hours ago, teknomedic said:

2 matched SSDs as a multi-device cache pool for redundancy

This would be good depending on size and could also have the boot partition.

4 hours ago, teknomedic said:

add one drive at at time to the main array to ensure stability

I always say, each additional disk is an additional point of failure. A parity disk plus only as many array disks as you need for capacity. You can always add more later when needed.

Thank you again! I appreciate your last thought too. I hadn't considered just expanding as needed even though that seems obvious. Still unlearning some old habits from more rigid software.

5 hours ago, teknomedic said:

A few questions and thank you in advance....

Welcome to Unraid — good questions for a first build.

One thing worth clarifying before committing to internal boot on your setup.

Your 4th Gen Haswell board almost certainly doesn't have TPM 2.0 support — which means internal boot would keep the USB drive required for licensing anyway.

You'd have two boot-related devices instead of one, adding complexity without the USB elimination benefit that makes internal boot most compelling.

For a first build that tradeoff is worth thinking through.

On using the remaining SSD space as a cache pool — the specific models of those older SATA SSDs matter more than their capacity for this decision.

Consumer SSDs from different eras contain very different NAND types, and in always-on 24/7 server duty the NAND type determines long-term reliability more than brand or capacity does.

An older SSD that's been sitting in a drawer unused could be excellent or problematic depending on what's inside it.

Before committing any drive to combined boot plus cache duty it's worth identifying the specific model and checking its NAND type.

The USB Flash section of this forum has a guide that covers exactly this — recently extended to include SATA SSD and NVMe selection for internal boot alongside the USB drive guidance.

The NAND hierarchy and what to look for applies directly to your decision.

For a first build the simplest reliable architecture is often a quality USB drive for boot and your matched SSDs dedicated entirely to cache pool — no partition complexity, full cache capacity available, hardware agnosticism preserved for the inevitable "I need to move this to different hardware" moment that every Unraid user eventually faces.

What are the specific models of those older SATA SSDs?

That would help narrow down whether combined boot plus cache is sensible for your situation.

Edited March 21Mar 21 by Lolight

Thank you for confirming the TPM issue. I did notice that mentioned in the video. My motherboard does have open TPM module pins so I think I could install a TPM 2.0 module, but haven't look into it. Does UnRaid support pre 2.0 TPMs if for some reason a 2.0 doesn't work on this motherboard?

Since the TPM might be an issue I am probably just going to do a USB boot to make things easier. Do dockers and app install on the USB? Just don't want to undersize it and regret it later.

I appreciated the information on SSDs in this scenario too, I hadn't really thought much about the NAND type being a concern, but what you say makes sense. I don't recall all the models or sizes just yet, I bought them a few years ago on sale and then tossed them into a box "for later" and I haven't dug out the box yet, lol.

2 hours ago, teknomedic said:

Does UnRaid support pre 2.0 TPMs if for some reason a 2.0 doesn't work on this motherboard?

Do dockers and app install on the USB?

Good questions — happy to clarify.

On TPM -- Unraid 7.3's TPM licensing requires TPM 2.0 specifically.

TPM 1.2 isn't supported.

Haswell boards vary on whether their headers support 2.0 or only 1.2 -- worth checking your motherboard manual before buying a module.

Given your motherboard generation USB boot with USB licensing is almost certainly the simpler and more reliable path anyway -- probably not necessary to pursue TPM at all.

On docker and apps — nothing installs on the USB drive.

Unraid loads into RAM at boot and the USB drive just holds the OS files, config, and license key.

Docker images and all appdata live on your array or preferably cache pool drives.

A 4GB drive is genuinely sufficient, 8-16GB gives comfortable headroom.

Don't let sizing concerns push you toward a large modern drive — smaller older drives from reputable brands are actually preferable for the reasons the USB flash drive guide covers.

On the box of SSDs — for your case these are most useful as cache pool drives rather than boot devices.

USB boot on a quality drive remains your simplest and most reliable path given the TPM situation.

When you dig out the box post the specific models here — depending on their age and NAND type they could be excellent cache pool candidates, which is exactly where SSD performance actually matters for Unraid's architecture.

Thank you again, after looking into the TPM support, this motherboard only supports TPM 1.2 modules, though I might have an avenue to get a modified BIOS that would enable 2.0 support. At this time that's too much work and I've settled on going the USB boot route. Your clarification helped me find a suitable USB stick to use.

Digging through the box, I found 2x Kingston A400 SATA SSDs (3D NAND / TLC) at 480GB each. The rest I have are smaller or have far less TBW. I'll probably avoid activating them until I'm done migrating my 30TB of data though.

I assume I can install the 480GB SSDs and then just not assign them to anything until I'm ready??

I appreciate the help and information!

26 minutes ago, teknomedic said:

Digging through the box, I found 2x Kingston A400 SATA SSDs (3D NAND / TLC) at 480GB each.

Good that you've settled on USB boot — the right call given the TPM situation.

On your question — yes, exactly.

You can install the SSDs physically and Unraid will see them in the interface but they won't participate in anything until you explicitly assign them to a pool. Unraid never touches unassigned devices without deliberate user action.

They'll just sit there visible but inactive until you're ready.

On the Kingston A400 480GB drives — worth a specific note before assigning them to cache pool duty.

The A400 series is one of the more documented examples of NAND lottery variance in the budget SSD market.

Kingston markets all variants as "3D NAND TLC" but the actual components vary significantly across production runs without any external indication of which variant you have.

The specific variants documented for the 480GB model include a Phison PS3111-S11 controller with Toshiba 15nm planar TLC — not true 3D NAND despite the marketing — which appears in units from approximately 2017-2018.

Later variants use Silicon Motion controllers with Micron or YMTC 3D TLC.

Some BOM analyses document QLC variants in certain revisions.

All carry the same model number, the same box, and the same rated specifications.

The Phison PS3111-S11 variants have a specific documented failure mode — "SATAFIRM S11" firmware panics where the drive becomes inaccessible until power cycle or worse.

For cache pool duty holding AppData and Docker configurations that failure mode is worth knowing about before committing the drives.

Since your drives came from a box purchased a few years ago the planar TLC Phison variant is a realistic possibility rather than an edge case.

Before assigning them to the cache pool run CrystalDiskInfo on both drives — it should show the controller identifier.

Phison PS3111-S11 in the output means the older potentially planar TLC variant.

Silicon Motion SM2259XT or SM2259XT2 means a more modern controller with higher probability of genuine 3D NAND.

If CrystalDiskInfo shows the Phison S11 controller it's worth researching that specific unit's NAND before committing it to always-on cache duty.

If it shows SMI the picture is considerably better — though NAND type verification through HWiNFO or physical inspection remains the definitive answer.

Happy to help interpret the CrystalDiskInfo output when you have it.

haha, of course I'd pick up something like that on sale. Certainly my kind of luck. I'll be sure to run them through crystal disk and get these ID'd soon. Worst case I'l re-purpose a 1TB 870 Evo and just not have redundancy for the Cache in the short term.

Thank you a ton on catching that quirk of my potential setup. Probably saved me a lot of potential future headaches.

Alternatively, My next best option for redundancy would be two 256GB SandDisk X400 SATA SSDs.

The X400 256GB has a fixed bill of materials with no production variance — Marvell 88SS1074 controller, DRAM cache, and SanDisk's own 15nm planar TLC NAND consistently across all documented units.

The consistent BOM is a genuine advantage over the Kingston A400's lottery situation.

The one limitation worth knowing is that 15nm planar TLC is older technology — 80 TBW endurance for 256GB is modest.

For typical AppData and Docker cache duties that aren't heavily write-intensive it's adequate.

So ranking your variants:

The Samsung 870 EVO 1TB is the strongest option by a meaningful margin — Samsung 128-layer 3D TLC, 1GB DRAM cache, 600 TBW endurance, five-year warranty, fixed BOM with no variance across production runs.

It sits at the top of the SATA SSD reliability hierarchy.

No redundancy on known excellent hardware is a better starting position than redundancy on hardware of unknown or older quality.

The SanDisk X400 256GB pair is a viable redundancy option — consistent and predictable, DRAM cache present, adequate endurance for the workload.

Older planar TLC but not disqualifying for cache pool duty.

The Kingston A400 pair is the unknown — run CrystalDiskInfo on both drives first.

If the controller comes back as Silicon Motion SM2259XT they're reasonable cache candidates.

If Phison PS3111-S11 appears the X400 pair is the stronger redundancy choice.

The CrystalDiskInfo result on the A400s determines which path makes the most sense for your specific situation.

Edited March 23Mar 23 by Lolight

I seem to have gotten a little lucky, both Kingston 480GB SSDs report the following:

Controller : SM2259XA (SM2259XT2) bufferless

FlashID: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die

Took me a little bit to find a program that would read them fully. Couldn't get this off CrystalDiskInfo for some reason or HardwareInfo either. Took a little program called "SMI Flash ID".

Again, I appreciate the heads up on the potential issues with the controllers in these SSDs.

2 hours ago, teknomedic said:

I seem to have gotten a little lucky, both Kingston 480GB SSDs report the following:

Controller : SM2259XA (SM2259XT2) bufferless

FlashID: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die

Took me a little bit to find a program that would read them fully. Couldn't get this off CrystalDiskInfo for some reason or HardwareInfo either. Took a little program called "SMI Flash ID".

This is excellent news for your Unraid setup.

This specific NAND is the polar opposite of the cheap QLC we were discussing.

Yeah, CrystalDiskinfo is of no use. I was under the assumption that it does show the controller ID.

Just tried on my drives - nothing.

And good job finding the SMI manufacturer tool -- those are your best bet if nothing else works.

Edited March 25Mar 25 by Lolight

If you read the notes you can still boot off an SSD on a computer without TPM. Spaceinvader also touches on this in his video. The only caveat is that you would need to leave the USB plugged in so it can use it for the license portion. You will still get all the performance advantages of booting off an SSD thou.

The boot performance benefit amounts to a few seconds saved on a machine that rarely reboots — essentially irrelevant in practice.

On this specific setup — Haswell without TPM 2.0 — internal boot keeps the USB drive required for licensing, so the result is two devices instead of one with no USB elimination.

The only other thing worth mentioning is some newer users have had high USB failure rates due to low quality Nand chips. Since it only uses the key on boot it could still be beneficial for some users. For myself my USB is from 2012 and I have not had any issues so will not be changing how it boots.

That 2012 drive is almost certainly large-node MLC -- exactly why it's still running perfectly.

The NAND era is what determines reliability, not the form factor.

Which is also why splitting boot and licensing across two devices doesn't really help -- neither function was stressing the original USB drive in the first place.

Near-zero workload on one device is the same as near-zero workload split across two.

Edited April 1Apr 1 by Lolight