> «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.»
I have left implicit a point that perhaps should be explicit: I
think that XFS metadata performance before 'delaylog' was pretty
good, and that it has remained pretty good with 'delaylog'.
People who complained about slow metadata performance with XFS
before 'delaylog' were in effect complaining that XFS was
implementing overly (in some sense) safe metadata semantics, and
in effect were demanding less (implicit) safety, without
probably realizing they were asking for that.
Accordingly, 'delaylog' offers less (implicit) safety, and it is
a good and legitimate option to have, in the same way that
'nobarrier' is also a good and legitimate option to have.
So in my view 'delaylog' cannot be described boldly and barely
described, especially in this thread, as an improvement in XFS
performance, as it is an improvement in XFS's unsafety to obtain
greater speed, similar to but not as extensive as 'nobarrier'.
In the same way that 'eatmydata':
> The relevance of pointing out that there is a big tradeoff [ ... ]
> 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» [ ... ]
is a massive improvement in unsafety as the name says.
Since the thread is about maximizing safety and implicit safety
too, technical arguments about changes in operational semantics
as to safety are entirely appropriate here, even if there are
those who don't "get" them.