> «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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
