{"slug": "ext4", "name": "ext4", "category": "files", "category_name": "Files, sync and backup", "description": "", "recommenders": 5, "commenters": 18, "warners": 3, "score": 4.172, "rising": 1.02, "first": "2025-11-11", "latest": "2026-09-12", "why": "On my NAS, I've been using ext4 with SnapRAID and mergerfs for years without issues.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 7, "compare": 3, "warn": 3}, "spark": [0, 0, 2, 0, 0, 1, 0, 0, 0, 0, 2, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "On my NAS, I've been using ext4 with SnapRAID and mergerfs for years without issues.", "kind": "", "icon": false, "domain": null, "github_repo": null, "official_url": "https://ext4.wiki.kernel.org", "pricing": "", "aliases": ["ext4"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 794794624, "item_id": 49674664, "url": "https://news.ycombinator.com/item?id=49674664", "by": "Delk", "date": "2026-09-12", "stance": "recommend", "quote": "I'm honestly not sure I've ever seen any unrecoverable corruption on ext4 or ext3", "excerpt": "> In the last decade, keeping my OS on a different volume from my data in `/home` has saved my work at least 5-10 times. Mine is of course just another anecdote, but despite seeing some crashes or hangs over the years, I can't remember the last time I've even had to manually fsck my ext4 filesystems, and I'm honestly not sure I've ever seen any unrecoverable corruption on ext4 or ext3. (I'm not saying it doesn't happ", "context": "", "use_case": "Personal machine root filesystem", "switched_from": "", "story": "Stop making swap partitions\u2014use swap files instead"}, {"id": 793518608, "item_id": 49594913, "url": "https://news.ycombinator.com/item?id=49594913", "by": "bayindirh", "date": "2026-09-07", "stance": "recommend", "quote": "anti-fragmentation features of EXT3/4 kept that one seek pretty cheap", "excerpt": "Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency. The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file. With NVMe disks or", "context": "", "use_case": "Filesystem (ext3/ext4)", "switched_from": "", "story": "Windows 11's \"special\" developer edition looks like another marketing misfire"}, {"id": 764915137, "item_id": 47807196, "url": "https://news.ycombinator.com/item?id=47807196", "by": "060880", "date": "2026-04-17", "stance": "recommend", "quote": "Switched to ext4 and never looked back.", "excerpt": "Same here. Had a production node running btrfs under heavy write load (lots of small files, frequent creates) and spent two days debugging what turned out to be filesystem-level corruption. Switched to ext4 and never looked back. The article doesn't mention what filesystem sits under Versitygw here, which seems like a pretty relevant omission for anyone thinking of replicating the setup.", "context": "", "use_case": "production storage", "switched_from": "Btrfs", "story": "Healthchecks.io Now Uses Self-Hosted Object Storage"}, {"id": 749482193, "item_id": 46842637, "url": "https://news.ycombinator.com/item?id=46842637", "by": "imiric", "date": "2026-01-31", "stance": "recommend", "quote": "On my NAS, I've been using ext4 with SnapRAID and mergerfs for years without issues.", "excerpt": "I'm currently troubleshooting an issue on my Proxmox server with very slow read speeds from a ZFS volume on an NVMe disk. The disk shows ~7GBps reads outside of ZFS, but ~10MBps in a VM using the ZFS volume. I've read other reports of this issue. It might be due to fragmentation, or misconfiguration, or who knows, really... The general consensus seems to be that performance degrades after ~80% utilization, and there ", "context": "", "use_case": "NAS filesystem", "switched_from": "", "story": "Guix System First Impressions as a Nix User"}, {"id": 746890659, "item_id": 46680666, "url": "https://news.ycombinator.com/item?id=46680666", "by": "p_ing", "date": "2026-01-19", "stance": "recommend", "quote": "ext4 is the only FS I'd want to see as first-party on Windows as a data drive.", "excerpt": "> Modern Linux supports asynchronous I/O. Not nearly to the depth and breth of NT. NT is async I/O throughout. Linux has a bunch of libs that ride on top of pretend async I/O with io_uring as a more recent bonus. > It's debatable whether NT's lack of memory overcommitting is a superior choice. NT won't randomly kill a process. That's the winning play. > OS personalities have never been relevant outside of marketing U", "context": "", "use_case": "", "switched_from": "", "story": "Prediction: Microsoft Is Going to Do the Funniest Thing Imaginable"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 786425200, "item_id": 49151575, "url": "https://news.ycombinator.com/item?id=49151575", "by": "Coelacanthus", "date": "2026-08-02", "stance": "warn", "quote": "if ext4 was used, it will be one of reasons.", "excerpt": "I don't know which filesystem was used. But if ext4 was used, it will be one of reasons. When you random write on ext4, and then do fsync, ext4 fast commit (introduced in 5.10) will combine them into a whole range from the lowest address to highest address, so it will sync far more data from actual modified data for random write. And even worse, if the range is larger than EXT4_FC_SNAPSHOT_MAX_RANGES, it will fallbac", "context": "", "use_case": "", "switched_from": "", "story": "Do not trust the marketing IOPS on Consumer SSD"}, {"id": 749571905, "item_id": 46848244, "url": "https://news.ycombinator.com/item?id=46848244", "by": "its_ubuntu", "date": "2026-02-01", "stance": "warn", "quote": "ext4 is all well and good until a power interruption or hard disk fault silently introduces some corruption", "excerpt": "I use ZFS on my system also, in a couple mirrors. I don't use any of the advanced features at all--just treat it like a big, reliable volume. I agree with your analysis. ext4 is all well and good until a power interruption or hard disk fault silently introduces some corruption in the middle of a file you were downloading, or zeroes one out, etc. That type of thing just doesn't happen with ZFS. My data has never felt ", "context": "", "use_case": "", "switched_from": "", "story": "Guix System First Impressions as a Nix User"}]}], "who": [{"by": "jcalvinowens", "context": "runs homebuilt NAS for a decade", "url": "https://news.ycombinator.com/item?id=46098862", "date": "2025-11-30"}], "tags": [], "use_cases": ["personal machine root filesystem", "filesystem (ext3/ext4)", "production storage", "indexing a file-based database", "filesystem", "nas filesystem"], "compared": [{"slug": "zfs", "name": "ZFS", "co": 9, "switched_from": 0, "switched_to": 0}, {"slug": "btrfs", "name": "Btrfs", "co": 4, "switched_from": 1, "switched_to": 1}, {"slug": "ntfs", "name": "NTFS", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "xfs", "name": "XFS", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "linux", "name": "Linux", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46835612", "title": "Guix System First Impressions as a Nix User", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=49618087", "title": "Stop making swap partitions\u2014use swap files instead", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49591036", "title": "Windows 11's \"special\" developer edition looks like another marketing misfire", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49148513", "title": "Do not trust the marketing IOPS on Consumer SSD", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48827325", "title": "How to Build a Minimal ZFS NAS Without Synology, QNAP, TrueNAS", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48047280", "title": "Removing fsync from our local storage engine", "mentions": 1}], "sentiment_by_month": {"2025-11": {"neutral": 2}, "2025-12": {"neutral": 1}, "2026-01": {"recommend": 2, "compare": 1, "warn": 1}, "2026-02": {"warn": 1, "compare": 1, "neutral": 1}, "2026-03": {}, "2026-04": {"neutral": 2, "recommend": 1}, "2026-05": {"compare": 1}, "2026-06": {}, "2026-07": {"neutral": 1}, "2026-08": {"warn": 1}, "2026-09": {"recommend": 2}, "2026-10": {}}, "quotes": [{"id": 794794624, "item_id": 49674664, "url": "https://news.ycombinator.com/item?id=49674664", "by": "Delk", "date": "2026-09-12", "stance": "recommend", "quote": "I'm honestly not sure I've ever seen any unrecoverable corruption on ext4 or ext3", "excerpt": "> In the last decade, keeping my OS on a different volume from my data in `/home` has saved my work at least 5-10 times. Mine is of course just another anecdote, but despite seeing some crashes or hangs over the years, I can't remember the last time I've even had to manually fsck my ext4 filesystems, and I'm honestly not sure I've ever seen any unrecoverable corruption on ext4 or ext3. (I'm not saying it doesn't happ", "context": "", "use_case": "Personal machine root filesystem", "switched_from": "", "story": "Stop making swap partitions\u2014use swap files instead"}, {"id": 793518608, "item_id": 49594913, "url": "https://news.ycombinator.com/item?id=49594913", "by": "bayindirh", "date": "2026-09-07", "stance": "recommend", "quote": "anti-fragmentation features of EXT3/4 kept that one seek pretty cheap", "excerpt": "Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency. The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file. With NVMe disks or", "context": "", "use_case": "Filesystem (ext3/ext4)", "switched_from": "", "story": "Windows 11's \"special\" developer edition looks like another marketing misfire"}, {"id": 786425200, "item_id": 49151575, "url": "https://news.ycombinator.com/item?id=49151575", "by": "Coelacanthus", "date": "2026-08-02", "stance": "warn", "quote": "if ext4 was used, it will be one of reasons.", "excerpt": "I don't know which filesystem was used. But if ext4 was used, it will be one of reasons. When you random write on ext4, and then do fsync, ext4 fast commit (introduced in 5.10) will combine them into a whole range from the lowest address to highest address, so it will sync far more data from actual modified data for random write. And even worse, if the range is larger than EXT4_FC_SNAPSHOT_MAX_RANGES, it will fallbac", "context": "", "use_case": "", "switched_from": "", "story": "Do not trust the marketing IOPS on Consumer SSD"}, {"id": 781264354, "item_id": 48829022, "url": "https://news.ycombinator.com/item?id=48829022", "by": "dapperdrake", "date": "2026-07-08", "stance": "neutral", "quote": "ext4 and mdadm can talk to each other.", "excerpt": "zpool-replace(8) https://openzfs.github.io/openzfs-docs/man/master/8/zpool-replace.8.html ZFS got this right. MDADM on ext4 somehow did not. EDIT: ext4 on MDADM. How ZFS gets this right: zfs(8) on zpool(8). So, basically, ext4 and mdadm can talk to each other.", "context": "", "use_case": "", "switched_from": "", "story": "How to Build a Minimal ZFS NAS Without Synology, QNAP, TrueNAS"}, {"id": 769232113, "item_id": 48077007, "url": "https://news.ycombinator.com/item?id=48077007", "by": "thomas_fa", "date": "2026-05-09", "stance": "compare", "quote": "which is more efficient than ext4 namespace management", "excerpt": "Thanks for the feedback, since I have relied in other thread related to O_DSYNC which a lot of folks have already suggested, and I will not repeat it here. For the benchmark results, and they were mainly due to metadata management. We have implemented our own KV store, see internal here [1], which is more efficient than ext4 namespace management, even after doing very aggressive fs tuning for that [2] (plus 65536 sha", "context": "", "use_case": "", "switched_from": "", "story": "Removing fsync from our local storage engine"}, {"id": 764915137, "item_id": 47807196, "url": "https://news.ycombinator.com/item?id=47807196", "by": "060880", "date": "2026-04-17", "stance": "recommend", "quote": "Switched to ext4 and never looked back.", "excerpt": "Same here. Had a production node running btrfs under heavy write load (lots of small files, frequent creates) and spent two days debugging what turned out to be filesystem-level corruption. Switched to ext4 and never looked back. The article doesn't mention what filesystem sits under Versitygw here, which seems like a pretty relevant omission for anyone thinking of replicating the setup.", "context": "", "use_case": "production storage", "switched_from": "Btrfs", "story": "Healthchecks.io Now Uses Self-Hosted Object Storage"}, {"id": 764596320, "item_id": 47787270, "url": "https://news.ycombinator.com/item?id=47787270", "by": "yabutlivnWoods", "date": "2026-04-15", "stance": "neutral", "quote": "linux + ext4 has atomic single and multi block writes as of 2025", "excerpt": "linux + ext4 has atomic single and multi block writes as of 2025: https://docs.kernel.org/filesystems/ext4/atomic_writes.html", "context": "", "use_case": "", "switched_from": "", "story": "Do You Even Need a Database?"}, {"id": 763029584, "item_id": 47689349, "url": "https://news.ycombinator.com/item?id=47689349", "by": "bullen", "date": "2026-04-08", "stance": "neutral", "quote": "uses the ext4 binary tree for indexing", "excerpt": "Yep, my distributed JSON over HTTP database uses the ext4 binary tree for indexing: http://root.rupy.se It can only handle 3 way multiple cross references by using 2 folders and a file now (meta) and it's very verbose on the disk (needs type=small otherwise inodes run out before disk space)... but it's incredibly fast and practially unstoppable in read uptime! Also the simplicity in using text and the file system sor", "context": "", "use_case": "Indexing a file-based database", "switched_from": "", "story": "Your File System Is Already A Graph Database"}, {"id": 754672384, "item_id": 47167024, "url": "https://news.ycombinator.com/item?id=47167024", "by": "lproven", "date": "2026-02-26", "stance": "neutral", "quote": "But I use ext4, yeah.", "excerpt": "> So the reasonable man uses Ext4 I guess. And the unreasonable one writes his own Unix clone... and ends up putting several multi-million-dollar companies out of business. I know which I admire more, TBH. But I use ext4, yeah.", "context": "", "use_case": "Filesystem", "switched_from": "", "story": "Bcachefs creator insists his custom LLM is female and 'fully conscious'"}, {"id": 750718865, "item_id": 46919929, "url": "https://news.ycombinator.com/item?id=46919929", "by": "mananaysiempre", "date": "2026-02-06", "stance": "compare", "quote": "Ext4 also stores small (~150B) files inside the inode", "excerpt": "> NTFS has a terrible design flaw which is the fact that small files, under 640 bytes, are stored in the MFT. Ext4 also stores small (~150B) files inside the inode[1], and so do a number of other filesystems[2]? NTFS was unusually early to the party, but if you\u2019re right that it\u2019s problematic there then something else must also be wrong (perhaps with the locking?) to make it so. [1] https://www.kernel.org/doc/html/lat", "context": "", "use_case": "", "switched_from": "", "story": "Microsoft open-sources LiteBox, a security-focused library OS"}, {"id": 749571905, "item_id": 46848244, "url": "https://news.ycombinator.com/item?id=46848244", "by": "its_ubuntu", "date": "2026-02-01", "stance": "warn", "quote": "ext4 is all well and good until a power interruption or hard disk fault silently introduces some corruption", "excerpt": "I use ZFS on my system also, in a couple mirrors. I don't use any of the advanced features at all--just treat it like a big, reliable volume. I agree with your analysis. ext4 is all well and good until a power interruption or hard disk fault silently introduces some corruption in the middle of a file you were downloading, or zeroes one out, etc. That type of thing just doesn't happen with ZFS. My data has never felt ", "context": "", "use_case": "", "switched_from": "", "story": "Guix System First Impressions as a Nix User"}, {"id": 749470000, "item_id": 46841875, "url": "https://news.ycombinator.com/item?id=46841875", "by": "awithrow", "date": "2026-01-31", "stance": "warn", "quote": "", "excerpt": "I'll bite. I use NixOS as a daily driver and IMO makes the underlying FS type even less important. If my main drive goes I can bootstrap a new one by cloning my repo and running some commands. For my data, I just have some rsyc scripts that sling the bits to various locations. I suppose if I really wanted to I could put the data on different partitions and disks and use the native fs tools but it's a level of detail ", "context": "", "use_case": "", "switched_from": "", "story": "Guix System First Impressions as a Nix User"}, {"id": 749482193, "item_id": 46842637, "url": "https://news.ycombinator.com/item?id=46842637", "by": "imiric", "date": "2026-01-31", "stance": "recommend", "quote": "On my NAS, I've been using ext4 with SnapRAID and mergerfs for years without issues.", "excerpt": "I'm currently troubleshooting an issue on my Proxmox server with very slow read speeds from a ZFS volume on an NVMe disk. The disk shows ~7GBps reads outside of ZFS, but ~10MBps in a VM using the ZFS volume. I've read other reports of this issue. It might be due to fragmentation, or misconfiguration, or who knows, really... The general consensus seems to be that performance degrades after ~80% utilization, and there ", "context": "", "use_case": "NAS filesystem", "switched_from": "", "story": "Guix System First Impressions as a Nix User"}, {"id": 747099809, "item_id": 46693738, "url": "https://news.ycombinator.com/item?id=46693738", "by": "magicalhippo", "date": "2026-01-20", "stance": "compare", "quote": "", "excerpt": "> I think you're missing the 2nd feature to the parent's point that I take issue with You're right, I did gloss over that point. I guess it should be noted that a lot of what fsck does[1] on say ext4 is something ZFS does on pool import, like replying the journal (ZIL) or trying older superblocks (uberblocks[2]). In that regard it's acting more like XFS[3] from what I can see. [1]: https://linux.die.net/man/8/fsck.ex", "context": "", "use_case": "", "switched_from": "", "story": "Understanding ZFS Scrubs and Data Integrity"}, {"id": 746890659, "item_id": 46680666, "url": "https://news.ycombinator.com/item?id=46680666", "by": "p_ing", "date": "2026-01-19", "stance": "recommend", "quote": "ext4 is the only FS I'd want to see as first-party on Windows as a data drive.", "excerpt": "> Modern Linux supports asynchronous I/O. Not nearly to the depth and breth of NT. NT is async I/O throughout. Linux has a bunch of libs that ride on top of pretend async I/O with io_uring as a more recent bonus. > It's debatable whether NT's lack of memory overcommitting is a superior choice. NT won't randomly kill a process. That's the winning play. > OS personalities have never been relevant outside of marketing U", "context": "", "use_case": "", "switched_from": "", "story": "Prediction: Microsoft Is Going to Do the Funniest Thing Imaginable"}, {"id": 738762402, "item_id": 46172650, "url": "https://news.ycombinator.com/item?id=46172650", "by": "finaard", "date": "2025-12-06", "stance": "neutral", "quote": "later phones switched to ext4", "excerpt": "I think the right way to do this is with snapshots, the way opensuse microos is doing it, for example. You get the best of both worlds that way - you still can easily install packages into the OS to customise it, and you do get painless updates and rollbacks. There's a very narrow use case where you _do_ want images, but for that you'll want to control the complete secure boot chain for attestation, so I'd dismiss it", "context": "", "use_case": "", "switched_from": "", "story": "Aurora: The Linux-based ultimate workstation"}, {"id": 737581795, "item_id": 46098862, "url": "https://news.ycombinator.com/item?id=46098862", "by": "jcalvinowens", "date": "2025-11-30", "stance": "neutral", "quote": "use ext4 with metadata_csum enabled, I guess.", "excerpt": "I've been running homebuilt NAS for a decade. My advice is going to irritate the purists: * Don't use raid5. Use btrfs-raid1 or use mdraid10 with >=2 far-copies. * Don't use raid6. Use btrfs-raid1c3 or use mdraid10 with >=3 far-copies. * Don't use ZFS on Linux. If you really want ZFS, run FreeBSD. The multiple copy formats outperform the parity formats on reads by a healthy margin, both in btrfs and in mdraid. They'r", "context": "runs homebuilt NAS for a decade", "use_case": "fallback filesystem", "switched_from": "", "story": "Don't throw away your old PC\u2013it makes a better NAS than anything you can buy"}, {"id": 734175088, "item_id": 45885943, "url": "https://news.ycombinator.com/item?id=45885943", "by": "nerdsniper", "date": "2025-11-11", "stance": "neutral", "quote": "APFS, NTFS, and Ext4 on the same drive", "excerpt": "Ext4 and NTFS. FUSE for linux and Paragon Software for MacOS. Though often I have three partitions, so I use APFS, NTFS, and Ext4 on the same drive.", "context": "", "use_case": "", "switched_from": "", "story": "SanDisk launches dongle-like Extreme Fit USB-C flash drive with up to 1 TB"}]}