Is it okay to install a NAS system drive using a USB drive? My 16GB USB drive only lasted four months
the night I installed Feiniu on the N100 mini PC, I didn't want to spend extra money on a system drive, so I pulled out a spare 16GB Kingston USB drive from a drawer and plugged it into the USB port at the back of the case as a system drive. Everything went smoothly during installation. Feiniu's system drive has a low threshold—8GB is enough, and 16GB is still too much for me. The first few months were peaceful, until one Thursday morning, my wife said the TV couldn't play cartoons on the NAS. I checked my phone and saw the device had been offline all night.
to get to the point: it can store and run, but USB drives are for consumables
to put the conclusion upfront: systems like Feiniu and Black Synology can boot, configure, and work normally on USB drives. After running for a month, you might even feel like you've gained a bargain—saving a drive or dozens of yuan on a USB drive. But the system drive is a job that gets chopped up 24/7, and the flash memory chips and main controller on a regular USB drive are consumables designed to "copy files occasionally." Doing the work of a long-term laborer with consumables, death is just a matter of time. Mine lasts four months, and some lucky enough to last a year. Essentially, there's no difference.
I later reviewed it, the problem wasn't the capacity at all. After installing the 16GB, the system is mostly left, and I've never felt a shortage of space. The real issue is the writing method , not the amount of writing.
What do
system disks usually secretly write
a data drive, writing large files can be done in a flash with hundreds of MB, and even mechanical drives can handle it. The system disk is the opposite, writing the 'small, fragmented, frequent' type:
| The approximate scale | characteristics of the source | |
| system logs (like /var/log) | from several MB to tens of MB | __ per day. HTML33__ add writes,|
| Docker the container layer all day | checking the number of containers, starting from tens of MB per day | and the parts that haven't been mounted out of the directory are all placed on the system disk |
| database has small transactions | volume, but fsync is extremely frequent | 4KB random writes, |
| indexes and inspection records tens of thousands of times a day | album index, SMART inspection | centralized scheduled tasks |
these items alone are insignificant; combined, they only cost a few hundred MB a day. My machine ran qBittorrent and Album, and there were no container logs at the time (I later calculated this in the about cleaning up the storage pool in —I could quietly write 8GB in half a year), plus Docker metadata and several databases. In four months, I estimate the total write was around 30GB. 30G doesn't sound like much, right? A 16GB drive is like writing the entire disk twice—and all of it is spent on a handful of hotspot blocks.
How My USB Drive Died: That Morning's Inspection Record
found out I was missing this morning, I pinged first, but it didn't work. Connect the monitor to the small unit and restart. It gets stuck mid-startup, and a line scrolls across the screen: sda: Write Protect is on — The system drive locks itself to read-only. Restart three times, and all three times get stuck in the same spot.
unplugging the USB drive into the computer, it can recognize the drive and read files, but copying anything inside will report write protection errors and the formatting will fail. When I checked the controller with ChipGenius, the drive was still alive. The controller detected too many bad blocks and proactively switched to protection mode—this was the USB drive's last words: better to lock than write to prevent faster data corruption. I copied the system files inside. I tried using mass-produced tools to flash the main controller, but after flashing, the capacity shrank. Even after reconnecting to the NAS, it wouldn't last a week. There's no need to save a 20-yuan drive.
those days, the NAS was down, but fortunately, photos and movies were on two data drives. After reinstalling the system, everything came back. The system drive failed, but the data drive remained intact. This architecture saved me—later, that replacement 64GB SSD also failed once, but reinstalling it still worked fine. That's another story. I wrote an article specifically about whether data will be lost if the system drive breaks will lost.
Why can't
U the disc hold up: three issues: particles, main controller, and wear balance
both flash memory, why can SSDs last ten years, while USB drives die in four months? Let's break it down and calculate three accounts.
the first stroke is the granules. TLC chips used in reputable SSDs, with a nominal erase and write lifespan of 1,000 to 3,000 cycles; To cut costs, USB drives use more scraps and white chip chips, so their lifespan is more than halved—after a few hundred uses, they're gone.
second stroke is wear equalization. SSD main controller has a complete FTL (Flash Transfer Layer) that spreads writes across the disk, rotating each block across the disk, with hotspots automatically leveling out. Ordinary USB drives either lack wear and tear balance or are extremely minimalist, with system logs and databases repeatedly writing to the same small area—a full drive written twice might be hundreds of times on hotspot blocks. 4KB small random write stacked with fsync is especially ruthless for write amplification, which is torture for a USB drive controller without cache.
third item is job matching. U drive is designed to copy files and then remove them, leaving them idle; The system drive feeds small writes 24/7 × without interruption. Running a marathon with a sprinter—no matter how well the pace is right, they'll still fall.
will also teach you how to check the write pressure on your own system drive—don't be like my hindsight work. If the SSD is plugged in, go into SSH and type smartctl -a /dev/sda, find the "Total Host Write Volume" line, and divide by the number of days powered on to get the average daily write speed; Then use du -sh /var/log to see how thick the log directory is. If you notice logs taking several gigabytes at a time, or a container is overclocking on the system disk, you can move the directory and add logs to the limit before it is written to your drive.
| media | low write tolerance | cost | when the system drive |
| a regular USB drive | poor, no wear and balance, | 0 yuan (gathering dust) | can run, but suddenly |
| SD card + reader | worse, There are also contact hazards: around | 20 yuan | which is even less convenient than USB drives |
| smaller capacity SSD | better, The main controller is fully armed | used 64GB is about 20 yuan | My final answer |
| the mechanical disc is divided into separate zones | and there's no PE concept | 0 yuan (existing listings) | if you're afraid of noise, don't consider it |
SD card: chips are the same source as the USB drive and even thinner. If you keep it powered through a USB card reader for a long time, it gets hot and has poor contact—a double debuff. Raspberry Pi fans are used to keeping two SD cards and swapping them out anytime, and that's for light load scenarios. NAS system setup is a task beyond imagination.
switched to 64G SSDs, the world quieted down
found a second-hand 64GB Kingston SSD for about twenty yuan, specifically as a system drive. After the change, I patched up the previous pitfalls one by one: Docker added size limits to the daemon.json, moved the database and download directories to data disks, and during the hibernation check, I also checked who was still copying secretly. More than a year later, the total write speed of this SSD has long surpassed that USB drive from back then—very stable—the main controller spreads write data evenly, while SmartCTL doesn't budge at all during health checks.
a quick alternative for budget-conscious users: partitioning the data drive to install the system is also an option. Feiniu can choose this option for installation. The downside is that the system data is on the same drive, and if the drive fails, it will be finished together. Fortunately, mechanical drives have much better write endurance and lifespan than USB drives, making them more reliable than sacrificing a single USB drive. That's exactly what I did when modifying my old laptop. The retired 64GB SSD was directly installed Feiniu by the system.
U the right positions in NAS: These three jobs are most suitable
I've said so much to tell everyone to throw away USB drives. It has three legitimate roles in the NAS community, all of which are light workloads that "write once, read for a lifetime":
| to use | ||
| Synology boot disk and | RR image is written to a USB drive using Rufus, Boot boot boot | boot guide to read only, not write, write once, use five years |
| system reset drive | U drive FNIOS_RESET set up labeled files in the directory | only insert when needed, usually lying down |
| the startup disk | write the system installation image | unplug it once it's finished |
Synology's setup takes USB drives to the extreme—guide USB drive placement, system installation hard drive. If you want to know more, check out my complete Synology installation guide . Password reset for Feiniu is also a USB drive's job, specifically mentioned in the about accidental deletion recovery in .
need to build the computer hands-on, follow this order: first decide where to place the system (excluding USB drives, choosing between SSD or partition), then plan how to arrange the data drives and choose the hard drives. After installation, remember to point Docker's logs and database directories to the data drive, so the system drive doesn't get hurt by it. If you choose the right system setup, you won't think about it for the next three years—that's proof it's doing well.
