[ ... ]
> Just ignore the troll, Stan.
It is noticeable that Stan and you have chosen to write offtopic
"contributions" that contain purely personal attacks in reply to a
technical point about «guidance on write-cache/barrier», but I'll
try to keep ontopic:
> [ ... ] irrelevant semantic arguments about the definition of
> "performance optimisation" [ ... ]
Oops, here is instead a (handwaving) technical argument, I
partially retract the above.
Note: I have 'grep'ed for «"performance optimisation"» and it
seems to me a made-up quote for this thread, and no argument
has been made by me about the «definition of "performance
optimisation"», and the above point seem to me a strong
misrepresentation.
The (handwaving) technical argument above seems to me a laughable
attempt to attribute respectability to the disregard for how
important is the difference between improving speed at the same
(implicit) safety level vs. doing so at a lower one, even more so
as (implicit) safety is an important theme in this thread, and my
argument (quite different from the above misrepresentation) was in
essence:
«There have been decent but no major improvements in XFS metadata
*performance*, but weaker implicit *semantics* have been made an
option, and these have a different safety/performance tradeoff
(less implicit safety, somewhat more performance), not "just"
better performance.»
The relevance of pointing out that there is a big tradeoff is is
demonstrated by the honest mention in 'delaylog.txt' that «the
potential for loss of metadata on a crash is much greater than for
the existing logging mechanism», which seems far from merely
«semantic arguments» as the potential for «many thousands of
transactions that simply did not occur as a result of the crash» is
not purely a matter of «semantic arguments», and indeed mattered a
lot to the topic of the thread, where the 'Subject:' is:
«raid10n2/xfs setup guidance on write-cache/barrier»
===============================
It seems to me that http://packages.debian.org/sid/eatmydata could
also be described boldly and barely as making a «significant
difference in [XFS] metadata performance» because its description
says «This has two side-effects: making software that writes data
safely to disk a lot quicker» even if continues «and making this
software no longer crash safe.»
If considering both the speed and safety aspect is irrelevant
semantics, then it seems to me that:
http://sandeen.net/wordpress/computers/fsync-sigh/
would be about «irrelevant semantic arguments» too, instead od
being a sensible discussion of tradeoffs between speed and safety.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
