Why I (almost) stayed with KMail

[Duncan]

Martin (KDE) posted on Sat, 30 Jun 2012 10:14:18 +0200 as excerpted:

> Mutt is nice if you have a command line only. But not a mail client you
> can give an inexperienced user.

I've never used mutt personally, but while I'm reasonably comfortable 
with the command-line and would likely adapt reasonably quickly to the 
command-line for mail if I needed to (FWIW, kmail orphaned by akonadi now 
on claws-mail myself, as regulars know given how happy I've been with it 
and thus my recommendation of it), mutt is said to have one VERY MAJOR 
FLAW for my usage:

Mutt depends on the still POSIX standard but inefficient and now 
considered legacy on Linux filesystem atime timestamps to track
read-mail.  Updating the atime anytime a file is accessed can be quite 
expensive indeed in terms of filesystem i/o, thus the modern kernel 
default of "relatime", updating it only the first time it's accessed in a 
day.

But btrfs' copy-on-write (COW) semantics, coupled with its COW-based 
snapshots, are set to make the problem MUCH WORSE.  Normally, COW-based 
snapshots are quite space-efficient, only taking up additional space 
where the data has changed between snapshots or between a snapshot and 
current.  But atime updates throw a wrench in things, because that means 
every time a file is accessed, its metadata has changed.  Now, consider 
what happens if you do a filesystem-wide grep, accessing all files in the 
process -- that's right, with traditional atime updates on access, 100% 
of the filesystem's metadata just got COWed!  Now consider the effect 
even with relatime (once-per-day atime updates) if that filesystem has a 
snapshotting script taking daily snapshots.  *NOW* consider the effect if 
for instance KDE's semantic-desktop is on, scanning everything daily or 
so to maintain its semantic-indexes!

That's right, the effect ends up being 100% metadata duplication with 
each daily snapshot!  Talk about a way to use up those multi-terabyte 
disks!

So there's some discussion of for instance setting noatime by default for 
btrfs.  That's going to break mutt, and a few other long outdated apps 
still relying on atime.  Another alternative would be recording atime 
separate from the rest of the metadata, so only the atimes will be 
updated, not 100% of the metadata, and this is very possibly what they'll 
do.  However, it's becoming increasingly apparent that atime simply 
doesn't fit in the modern filesystem setup, killing efficiency and 
reducing robustness especially for otherwise read-only task-sets.

And as I said, mutt is infamous among filesystem devs (and the distro 
folks that decide default mount-options for the distro as well) as one of 
the few apps that still depends on atime.

For quite some years now, I've run my systems with the noatime option for 
on-disk filesystems (I don't bother with virtual/memory-based filesystems 
like sysfs, tmpfs, devtmpfs, etc, so they stay at the kernel default 
relatime).  Thus, mutt would be broken on my system.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.