Lolight

Your confusion is understandable. In basic terms -- USB flash drives consist of two major components: controller and flash. It's the controller chip that generates heat even when there is nothing being read or written to the drive. Modern drives come with much more powerful controllers compared to the legacy ones. That extra processing power comes at the cost of additional heat. Controllers do many things: error correction, wear leveling, bad block management, garbage collection...Just to name a few. Legacy drive controllers are quite simple -- they're not capable of doing much; however, stable NAND does not require advanced features. Low NAND maintenance activity results in minimal heat. Those drives can last decades in the Unraid environment. Modern drives are the complete opposite -- unstable NAND requires lots of housekeeping by the controllers. Constantly active controllers mean lots of heat. BTW, you consistently mention the correct people and channels. Could you please share your sources? I'd love to learn from them as well.

The ten drives strategy works -- genuinely. If you're comfortable with the maintenance overhead of replacing drives every year it's a valid approach. No need to read any further. To your actual question -- removing counterfeits entirely, what's left? Think of NAND generations like city infrastructure. Older large-node NAND from 2007-2011 is like wide roads with generous lanes -- traffic flows freely, maintenance is minimal, the system runs reliably for decades. Modern QLC NAND is like the same roads rebuilt at a fraction of the width to fit more lanes -- traffic still moves but requires constant traffic management, lane corrections and active intervention just to prevent gridlock. That management overhead never stops regardless of how quiet the roads are. A 2008 drive in your always-on server is pretty much idle between reboots. A modern drive is running its traffic management system continuously -- generating heat and accumulating wear whether you're using it or not. Authenticity and brand don't change which kind of roads are inside the drive. Production era does.

The brand ownership point is accurate -- SanDisk and WD share manufacturing relationships, PNY and Verbatim have overlapping supply chains. That's genuinely useful knowledge for some purchasing decisions. For Unraid boot device selection it's the wrong variable though. The question isn't which brand to trust -- it's what NAND type is inside the drive regardless of brand. A genuine authentic WD drive manufactured yesterday contains the same small-geometry NAND as a genuine authentic SanDisk manufactured yesterday. Both will generate the same continuous idle controller heat in always-on server duty. Both come from reputable sources. Neither counterfeit concern applies. Neither is suitable for long-term always-on boot duty. The Pepsi vs Coke framing works when the products are genuinely equivalent. USB flash drives aren't equivalent across production eras -- a genuine 2008 PNY Attache and a genuine 2024 PNY Attache contain fundamentally different storage technology with fundamentally different reliability characteristics in always-on conditions. That's not brand preference -- it's physics. The backup solution framing is fair as far as it goes -- recoverable failures are less catastrophic than unrecoverable ones. But preventable failures are better than recoverable ones. The guide's point isn't that USB failures are catastrophic. It's that they're predictable and avoidable through hardware selection -- which makes the backup solution a safety net rather than a substitute for getting the hardware right.

When it arrives and you run ChipGenius could you post the full output here along with the full model name, P/N from the packaging and the country of manufacture if it's printed there? "Flash Drive Information Extractor" output would also be a bonus. The reason — there's a companion thread in the USB Flash section documenting verified NOS MLC drives with confirmed specs. A 2007 copyright PNY Attache variant with confirmed components would be a useful addition to that reference for anyone else shopping for the same hardware on eBay.

To clarify for @imrobertcampbell -- the "constant use" isn't about read/write activity from the OS. It's about the drive being powered on continuously in an always-on server environment. Modern consumer USB flash drives use NAND at very small node geometries -- the same technology as budget SSDs. At those geometries the controller has to continuously scan cells, correct errors and refresh charge states regardless of whether anyone is reading or writing to the drive. That maintenance workload generates heat around the clock even when the drive appears idle from the OS's perspective. The counterfeit concern is real but secondary. A genuine modern SanDisk from a reputable retailer still contains the same small-geometry NAND that makes it unsuitable for always-on duty. Authenticity doesn't change the underlying physics. NewDay's explanation is correct — the drives that survive years of always-on server duty are overwhelmingly from the 2007-2011 era when larger node geometry produced inherently more stable NAND that requires minimal controller maintenance at idle. The USB Flash section guide covers the full technical explanation and verification methodology if you want the complete picture before your solution comes together tomorrow.

I'm not OP. I bet he was pointing out his recent discovery of the fact that SanDisk is by far the most counterfeited brand in the world. While Kingston and others are also heavily counterfeited, SanDisk wins by a large margin because of its stronger brand premium and broader global recognition. Also SanDisk's proprietary controllers significantly complicate the discovery of fakes. ChipGenius and similar tools often (always) fail or give incomplete information. This is one of the main reasons SanDisk drives are both highly counterfeited and much harder to verify compared to most other brands. SanDisk fakes are particularly insidious: counterfeiters can hide behind the "proprietary controller = unknown info" behavior that real SanDisk drives also exhibit. The only way to detect the worst of Sandisk fake drives is by capacity verification with tools like H2testw, f3, FakeFlashTest. The problem is that most of modern fakes deliver full capacity on inferior components - cheap controllers paired with rejected/down-binned NAND.

Good find on the PNY Attache. Since you're on a trial the sequence is slightly different from a paid license transfer — trials can't be transferred, only paid licenses can. Cleanest path: Back up your current SanDisk drive through Main --> Boot Device --> Boot Device Backup. Use the USB Flash Creator on the PNY drive -- select "Use custom" and point it at your backup ZIP file. This migrates your entire configuration across automatically. Boot with the PNY drive. Purchase the license and register it on the PNY drive through Tools --> Registration. The SanDisk gets left behind rather than blacklisted -- trial licenses don't trigger the blacklist mechanism that paid license transfers do. One question — have you already purchased the PNY drive? If not share the eBay listing here for a quick check. The specific model and production era matter -- not counterfeit risk with genuine NOS drives, but making sure the listing is actually the right vintage rather than a later production drive described loosely as old stock.

Worth noting -- syslog to flash is optional and off by default. In standard configuration the write activity is minimal. The bigger issue for modern consumer drives isn't write activity at all -- it's idle controller heat from NAND instability running continuously regardless of user I/O. A QLC drive generates that maintenance workload whether you're writing to it or not. Which is why drives fail in always on duty even on systems that change configuration rarely -- the failure mechanism is the NAND type rather than the usage pattern. The USB Flash section guide covers exactly this.

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.

Good point on ASPM and USB suspend — that's a separate failure mode worth ruling out in BIOS independently of drive quality. The drive failing ambiguously rather than obviously can lead you down a very expensive rabbit hole. The Bar Plus at three years tracks — it's the least bad widely available option rather than a genuinely reliable choice for Unraid.

That would be great! 👍

Some additions and refinements worth considering: On power consumption -- the idle current draw is determined by the controller's workload rather than by system power management. A controller managing QLC NAND's 16 voltage states continuously draws more idle current than a controller managing stable large-node MLC regardless of what the USB bus or system does. The NAND type determines the controller's idle workload -- which determines the heat generated -- which determines the degradation timeline. On luck -- the variance between drives lasting weeks and drives lasting 10+ years isn't random. It's determined by NAND type and node geometry. The 10+ year drives are almost universally large-node MLC from the pre-2012 production era. The drives failing in weeks or months are overwhelmingly modern consumer drives with QLC or late-node TLC NAND. The outcomes are deterministic and verifiable rather than luck-dependent -- which matters because deterministic outcomes are addressable through hardware selection while random outcomes aren't. On brand quality -- the declining quality is universal across consumer brands rather than specific to lesser-known manufacturers. Samsung, Kingston, SanDisk -- all current consumer USB flash drives from major brands use NAND that makes them unsuitable for always-on boot duty. The relevant quality signal is NAND type and node geometry rather than brand reputation. On cooling -- USB drives have never had meaningful thermal management beyond metal casing. The thermal problem in modern drives isn't inadequate cooling of otherwise stable NAND -- it's that QLC and late-node TLC NAND generates continuous controller heat from instability-driven maintenance workload regardless of the drive's physical design. Better cooling of an inherently hot controller is less effective than selecting a controller with inherently low idle heat requirements. The USB Flash section guide covers the NAND hierarchy and ChipGenius verification methodology that makes the "can't keep a list" problem tractable -- chip-level verification remains valid regardless of model changes and counterfeiting.

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.

I have to disagree with you on that. There's nothing inherently wrong with using specific consumer drives 24/7. A legacy, large node MLC NAND USB flash drive is a perfect fit for the 24/7 duty in Unraid. Stable NAND paired with a simple controller (nearly zero activity/heat) is what makes it so reliable. Granted, modern enterprise drives universally come with much more advanced controllers than legacy drives. However, this is driven by necessity rather than choice. Modern NAND flash is significantly less stable and requires more sophisticated error-correction algorithms to ensure reliability.

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.

Check out the last section of the guide: https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/

Excellent persistence working through that — the mount point collision was genuinely non-obvious and not something the standard troubleshooting sequence would have surfaced directly. That's a Garuda Linux specific behaviour where the automounter assigns mount points in a way that can create path conflicts between multiple devices. The VID/PID confirmed the drive is exactly what it should be -- correct for Unraid boot duty. Everything that followed was Linux filesystem management rather than anything wrong with the drive itself. Glad it's working. Enjoy the new Unraid setup!

Good news — the VID/PID confirms this is exactly the right drive. Your drive's ID 0930:6545 matches the verified PNY Attache Optima Pro with Phison PS2231 controller and very likely to contain the exact same, hard to find 56nm Toshiba NAND (see the MLC-based consumer USB Flash Drives thread for specs). The mounting errors and partition manager findings point to a different problem than permissions — the drive has an existing partial Unraid partition structure from a previous write attempt that's confusing the system. The 3MiB unallocated region is the Unraid boot partition's reserved space and the filesystem the system is trying to mount isn't a standard Linux filesystem -- which explains every error you're seeing. The fix is to completely wipe the existing partition table before trying the USB Creator again. Run these commands in sequence -- replace sdX with your confirmed device identifier from lsblk first: lsblkConfirm the PNY drive's identifier, then: sudo wipefs -a /dev/sdX sudo sgdisk --zap-all /dev/sdX sudo partprobe /dev/sdXThe wipefs command removes all filesystem signatures. The sgdisk command destroys both MBR and GPT partition tables completely. Together they return the drive to a blank state that the USB Creator can write to cleanly. Unplug and replug the drive after running these commands, then attempt the USB Creator again before the system automounts anything. Garuda Linux uses KDE's device notifier aggressively — if it tries to automount between the wipe and the USB Creator attempt run: sudo systemctl stop udisks2Then run the USB Creator, then restart udisks2 afterward with: sudo systemctl start udisks2Let me know what the USB Creator produces after the full wipe.

Thank you — both answers are very helpful. On the license drive point -- just to confirm the practical implication. Once the boot pool is established and the license file is copied to it, can the original USB flash drive be physically removed permanently? Or does it need to remain present for ongoing license validation even though it's not mounted? If the USB drive can be removed after initial setup that changes the configuration picture significantly -- USB licensing users would achieve complete USB elimination through the mirrored boot pool without needing TPM, which wasn't previously understood to be possible.

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.

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.

The idProduct string showing multiple OEM names is noted — but to confirm this matches the verified unit we need the VID and PID values from the lsusb output. Can you share the full lsusb line for the PNY entry — it should show something like: Bus 00X Device 00X: ID xxxx:xxxx Kingston...The four digit values after "ID" are the VID and PID. For the verified unit those should be VID 0930 and PID 6545. If they match we can confirm the controller. If they differ it's worth knowing before proceeding further. On the formatting error — since the commands executed successfully but the USB Creator still fails the issue is almost certainly a permissions conflict between the USB Creator's process and udisks2. Try this sequence: First confirm your device identifier — run: lsblkIdentify the PNY drive's device identifier in the output before proceeding. Verify carefully — the next commands are destructive and writing to the wrong device causes irreversible data loss. Then with the correct identifier confirmed completely close the USB Creator application and run: sudo umount /dev/sdX sudo dd if=/dev/zero of=/dev/sdX bs=4M count=10 status=progress sudo partprobe /dev/sdXReplace sdX with your actual device identifier from the lsblk output. Then reopen the USB Creator immediately and attempt the write before the system automounts the drive again. If that still fails try running the USB Creator with elevated permissions: sudo unraid-usb-creatorOr whatever the specific executable name is for your distribution. The underlying issue is the USB Creator and udisks2 competing for device control — running the Creator with sudo gives it priority over the daemon. If neither works let me know your Linux distribution and desktop environment — some distributions have specific udisks2 permission configurations that require an additional step.

@JorgeB One more clarification if you don't mind — two questions: Does the onboarding wizard present USB flash drives as selectable boot pool devices in its interface, or does creating a USB mirrored boot pool require manual configuration outside the wizard? And on the license drive — in the mirrored boot pool configuration where the license USB drive serves purely as a license holder with no boot function, is there a minimum size requirement for that drive? The key file itself is kilobytes in size so theoretically any recognized USB device should work — but whether the licensing system has its own minimum size requirement independent of the boot drive requirements isn't documented anywhere I can find.

Thanks to @JorgeB confirmations above this is worth highlighting for anyone currently evaluating their boot options. A mirrored boot pool from two USB flash drives or industrial DOMs is confirmed supported in 7.3 -- USB devices work in boot pools, tested by JorgeB. The configuration is: Two USB flash drives or DOMs forming the mirrored ZFS boot pool -- providing redundancy against single drive failure. The existing USB license drive remaining in place as the license holder -- or TPM if available. One important constraint JorgeB flagged -- boot pool devices need to be 16GB minimum. The 16GB minimum restriction applies specifically to boot pool member devices — because those devices get the 50% partition rule applied to them during boot pool setup. The license drive bypasses that entire partition process entirely. This addresses the single-point-of-failure concern without requiring internal drive slots, TPM hardware, SATA or M.2 ports. For users with internal USB headers: two industrial USB DOMs of 16GB or larger or USB drives mounted internally via inexpensive 9-pin to USB-A adapters in the boot pool mirror plus the existing license drive on an external port or internal adapter is a particularly clean configuration -- redundant boot, no internal slots consumed, full hardware agnosticism preserved. The 16GB minimum means NAND type verification matters for the boot pool drives -- the same NAND quality considerations that apply to internal NVMe selection apply here. Verified 3D TLC or better from a reputable manufacturer at 16GB or above is the target. The USB Flash section guide covers NAND type identification and verification. This configuration wasn't mentioned in the promotional materials or tutorial videos. The USB Flash section guide will be updated to include it as a confirmed supported configuration.

The USB_TRANSPORT exclusion appears in dconklin's bug report from this thread -- posted Thursday at 7:39 PM. His onboarding wizard showed it as a disk check failure reason. Good to know it was a development-stage consideration that didn't make it to release. This confirmation changes the practical picture significantly. A mirrored boot pool from two quality USB flash drives or industrial DOMs -- with the existing license USB drive remaining in place -- addresses the single-point-of-failure concern for the broadest possible user base without requiring internal slots, TPM hardware, or NAND quality decisions beyond the existing USB guidance. Given that this wasn't mentioned in the promotional materials or tutorial videos it's likely totally unknown to most users currently evaluating their boot options. Worth prominent documentation -- it's the most accessible redundant boot configuration available and it works with hardware most Unraid users already have.