I actually did a bit of research and found the old thread, honestly. I
thought this might not be a shoo-in. :) Seems worth hashing out, though.
But if journali[zi]ng guarantees are thrown out the window by volatile
caches on disk, why bother with the half-solution? Slower while you
run, worthless when you lose power? Sounds like the worst of both
worlds. (well, ok, experience shows that it's not worthless in practice...)
Hm, how would we know, really? What does it look like? It'd totally
depend on what got lost... When do you find out? Again depends what
you're doing, I think. I'll admit that I don't have any good evidence
of my own. I'll go off and do some plug-pull-testing and a benchmark or
two.
But, drive caches are only getting bigger, I assume this can't help. I
have a hard time seeing how speed at the cost of correctness is the
right call...
SuSE does (via patch for ext3). Red Hat & Fedora don't, and install by
default on lvm which won't pass barriers anyway. So maybe it's
hypocritical to send this patch from redhat.com :)
And as another "who uses barriers" datapoint, reiserfs & xfs both have
them on by default.
I suppose alternately I could send another patch to remove "remember
that ext3/4 by default offers higher data integrity guarantees than
most." from Documentation/filesystems/ext4.txt ;)
-Eric
--
