Should you choose ext4 or Btrfs for a NAS hard drive? I checked late at night the day of the flying bull, now there are two options for you to copy from two plates

first time installing Feiniu, three options popped up at the storage space creation step: ext4, Btrfs, and ZFS. I stared at the screen for ten minutes—if I picked the wrong dial, would this thing be ruined? I scrolled through forums until 1 a.m., and the next day gritted my teeth and chose Btrfs. More than a year passed, and now I have two machines and three drives at home, running two file systems mixed together, each doing their own thing. This article thoroughly explains the matter, so you don't have to dig through the night.

first speak file systems in plain terms, don't be scared by the terminology

file system is essentially the "ledger" on the hard drive. Every document you save must be recorded in this ledger "where, how big, and when it was written." ext4 is an old ledger that the Linux world has used for nearly twenty years—purely handwritten as a running log. Its advantages are stability and speed—even a master repair shop can handle it with their eyes closed. BTRFS is a new generation ledger, with each account come with an anti-counterfeit code and can be fully copied.

So the difference between the two isn't about "saving files"—both can be saved, and when you mount them daily, you can't tell who's who, whether it's 110MB/s or 110MB/s. The difference all comes after something happens: the drive quietly breaks, the file slowly rots, or the wrong one deletes the wrong one when your hand trembles—who can save you? Choosing the file system essentially means choosing "treatment after an incident."

Btrfs three signature skills, but EXT4 can't provide any of them

First: Snapshots. Take a "photo" of the entire shared folder in seconds, recording only changes without copying data, taking up almost no space. Accidental deletion, ransomware encryption, careless modifications to incorrect configurations—just roll back to the moment you took the photo. In my post about installing three barriers on my home NAS to prevent ransomware, I mentioned that snapshots are the first barrier—ransomware uses your normal permissions to encrypt files, RAID can't save you, but can snapshots be targeted by ransomware NAS The premise is that you have selected Btrfs; ext4 doesn't have this feature at all.

second item: verification. mechanical disks remain unused, the data will quietly flip positions—in jargon, it's called position corruption. An old photo wastes a corner, a video gets stuck and can't play, but the disk itself is SMART and everything is normal—this isn't mystical, it's real. ext4 is completely unaffected by this kind of damage; it reads whatever it reads and trusts accordingly; Each data block in Btrfs comes with a check code. Running Scrub inspection can identify bad blocks. If you build RAID1, it can also use another disk to automatically fix the replica.

Third item: compression. zstd transparent compression—automatically compressed during writing and automatically decrypted when read, leaving you completely unaffected. Documents, virtual machine images, database backups, etc., can save 20-30% of space—it's a waste. But photos and videos are pre-compressed from the factory, so it's basically impossible to press down. Don't expect it to load double movie for you.

by the way, let's talk about how to enable compression and inspection. For compression, you can't find a switch in the graphical interfaces of Synology or Feiniu. You need SSH to change the mount option in the command line, compress=zstd:3 like this. After modification, it only works on newly written files; old files won't be repressed. If you find it troublesome, don't bother with it; it's just icing on the cake, not a must-have. Scrub inspection is more important: Synology has graphical buttons in the storage pool menu, and you can set periods in the planning tasks; For Feiniu, you have to type it yourself. Use btrfs scrub start plus your mounting path. A single 8TB drive runs for three to four hours, and during that time, it runs as usual without downtime. I run every Sunday night, glance at error correction statistics after running, and if there are zero errors, I go to sleep; if there are errors, it's time to keep track of the stock.

ext4 is not a negative example; its reasoning is very practical

Btrfs those skills come at a price. Its write-time copy mechanism (editing files doesn't mean changing them on the spot; you copy a new copy first, then change the pointer) is inherently unfriendly to high-frequency, small writes: write a little, copy a piece, and that's how the write scale is achieved. QBitTorrent doing seeding while running and running databases in Docker—these kinds of daily small tasks are handled more efficiently by ext4.

then the threshold. The official BTRPS recommendation is to start with 4GB RAM. Your old box with 2GB RAM or the 100M mini cannon with N1 flashing is much lighter to run on the EXT4. There's also a category where data is simply worthless: movies and series are downloaded and then deleted, and if they fail, they can be re-downloaded. Snapshot verification is meaningless to them, so why pay extra for that?

I have two machines with three discs, and the selection method is completely different

my main N100 Feiniu, which has over 40,000 family photos and historical documents, I chose Btrfs. Photos are non-regenerosial; snapshots run with the "one per day for seven days, one per week for four weeks," and Scrub manually runs them once every quarter. The download drive was the SSD cache I bought for 430, which I removed and reused as useless, and I partitioned it into a separate ext4 format—qBittorrent nags on it every day, and snapshots are pointless for the download repository, and copying when writing just makes things messy. Also, the Tai-Lao DS220j serves as an offline backup repository. Ext4 is dedicated to archiving—the simpler, the more reliable.

Here are

test numbers: for the same 8TB mechanical drive, Ext4 sequentially copies large files at 172MB/s, Btrfs at 168MB/s, with about 4 differences visible to the naked eye; What really sets the gap is that after switching the downloader back to the ext4, the system load during the early morning planting hours visibly decreases. So don't be swayed by the word "performance"—the difference in read/write order is something you can't even notice in a family scenario.

three pitfalls you must know before you start

pitfall one: Once the grid is set, you can't switch. file system is created, there is no direct conversion path. To switch from ext4 to Btrfs, you have to move data out, delete space to rebuild, and then move it back—essentially reinstalling everything. So when you set up storage, you have to think carefully. Don't be like my friend, who used Ext4 to store photos for two years and then moved data for a whole weekend just to snap photos. I've written about the process of disk replacement migration. If you really get to that point, just follow it: NAS how to migrate data from a new hard drive

pitfall 2: Docker database containers need to be handled separately. Immich. For containers like MySQL with databases placed on Btrfs, directories must be set to disable write-time replication (nodatacow), otherwise fragments will accumulate and performance will degrade significantly. But note, if you turn it off, checks and compressions also fail for this directory—consider it yourself. If you don't know how to set it, the article on container directory mounting explained how to correctly mount the path: Feiniu Docker directory mount .

Plot 3: Snapshots aren't just for free. snapshot chains are too long, space will gradually be eaten, files won't be freed after deletion, and the corresponding snapshots must be deleted together before they can be released. Follow the retention policy and clean regularly. Don't just stare blankly after a year thinking, "Why is it still full after deleting 3T?"

if you've been using the Ext4 for two years and your palms are sweating at this point, there's no need to rush to reframe it. Snapshots are 'regret medicine,' not 'life-saving talismans.' The real lifesaver has always been backups. Offline backup drives are solid, ext4 sleeps soundly, and when the drive is swapped to expand, switching to Btrfs is not too late.

say more about ZFS, so no one will be upset. It truly is a heavyweight player in file systems, with snapshots, verification, RAID-Z, and everything you need. If you want to nitpick, Btrfs is considered semi-professional compared to it. But the cost is clear: memory really consumes a lot, and it's widely accepted in the industry that starting at 8GB is the most respectable option; Feiniu's current ZFS interface can't even adjust recordsize, nor can subsets be created—it's a semi-finished product. The expansion rules are rigid, and adding a pool after building it feels awkward. If you really need enterprise solutions, just go for TrueNAS. For home use, don't make this a problem for yourself.

just copy the

Synology DSM7 is now officially recommended for most scenarios, and Feiniu's snapshot feature is also exclusive to Btrfs, so if you're really stuck, just ignore Btrfs—the direction is always right. But remember this: snapshots only manage "rollbacks," not "fire and continuous camps." The offline leg in the 3-2-1 backup principle must be preserved. This article explains why: how to do NAS data backup to ensure safely. I previously recorded the complete operation of mounting a new drive: lsblk searches for a one-stop formatting process: the Feiniu to fully record the second hard drive. The health of the hard drive itself is another matter. How to keep an eye on SMART in this article: What are the warning signs NAS a broken hard drive ?

In the end,

sums it up in one sentence: data is valuable and you can take snapshots with Btrfs; if data is renewable, ext4 is worry-free. Mixing two drives is the normal form of a home NAS.