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.
