Wasn't part of the need for Maildir indexability rather than reliability?

It provides both. mbox was a known evil 20 years ago, so it's a bad example for the article.

The qmail spec describes queuing and delivery in a filesystem-safe manner.

> Filesystems have evolved. ZFS has been available for ten years.

Perhaps you should examine the section discussing the various problems with file systems. ZFS is hardly immune from these problems.

Perhaps you should take a closer look. ZFS wasn't part of that discussion, and none of the file systems which were discussed have ZFS's feature set.

I wonder how close btrfs is to ZFS. And how exactly it differs.

The similarity is specious. That is, if you look at a feature listing, they look similar. But dig into details and they clearly differ.

Origins: one starts out with proprietary developed functionality and with tons of money in a skunkworks project, using a consolidated team of developers mainly within one company through the fs development and stabilization; the other starts with an idea in a research paper (not called btrfs then because it wasn't an implementation), slow recruitment that'd eventually involve dozens of major companies, and is on a split stabilize and feature development track.

And then if you go back to look at features (commands in particular) in more detail there are some big differences that may or may not affect specific workflows. e.g. btrfs snapshots are unique and independent file trees, in effect there's no distinction between the original and snapshot, both are read-writable, modifying one doesn't affect the other, either can be deleted without affecting the other (ZFS has a distinct parent-child relationship between filesystems, clones, snapshots). Growing btrfs volumes by adding then (at some point balancing, which may be optional depending on the utilization and layout) is a lot easier and faster than ZFS. ZFS offers raid7 (3 parity drives), Brfs does not. Btrfs offers online defragmentation, ZFS does not. ZFS is more stable for $reasons. Really even ext4 and XFS are considered more stable still, although I hesitate to say Btrfs is not stable or unstable. I'd say Btrfs is earning trust, where the others have earned it (with very edge case exceptions, and there simply are more such edge cases for Btrfs still being found and fixed)

So they're actually quite different.

The article is a troll with some good information.

I've been a heavy mail user for years... Never encountered data loss due to file system problem, and honestly I can't think of a time in the last decade where anyone I'm acquainted with has. (And I ran a very large mail system for a long time)

Hell, I've been using OSX predominately for years now, and that garbage file system hasn't eaten any data yet!

There are problems, even fundamental problems, but if someone is literally unable to use any mail client, you need to look at the user before the file system.

Where I think you're seeing "that garbage file system" not eating your data has a lot to do with no crashes or power losses. It has evolved a good deal since HFS and even HFS+ days, no one uses either of those anymore. It's all HFSJ, with a scant number using HFSX.

20 years ago Mac OS crashed often, and had a file system not designed to account for that. OS X even shipped with non-journaled HFS+. It was only into the 3rd major release of OS X that journaling appeared. Data corruptions, I feel, dropped massively, because the OS didn't crash nearly as often, but did still crash. In the last 4-5 years I'd say I get maybe one or two kernel panics per year on OS X, which is a lot less than I get on Linux desktops. But even still on Linux desktops, I can't say when I've seen file system corruption not attributable to pre-existing hardware issues.

Cough, cough. MH.

What, you don't think MH was doing better file handling than mbox, including most of maildir's techniques, a decade before maildir?