0

We seem to be having trouble with some metadata update performance on CentOS6, so I am checking to see if we have the improvements mentioned in this presentation by Dave Chinner:

http://xfs.org/images/d/d1/Xfs-scalability-lca2012.pdf

It mentions these historical problems:

XFS's Metadata Problems

  • Metadata read and lookup is fast and scales well.
  • Metadata modification performance is TERRIBLE.
  • Excellent transaction execution parallelism, little transaction commit parallelism.
  • Typically won't scale past one CPU.
  • Transaction commit throughput limited by journal bandwidth.
  • Metadata writeback causes IO storms.
  • Lots of locks to deal with.

I can't find what the release vehicle would have been in order to track down the fixes he presents.

CentOS6/RHEL6 is fairly is running a fairly old kernel, 2.6.32, and I'd like to determine if we are running the improvements referred to in the presentation.

More information:

$ modinfo /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/fs/xfs/xfs.ko
filename:       /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/fs/xfs/xfs.ko
license:        GPL
description:    SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
author:         Silicon Graphics, Inc.
srcversion:     67725EF8353DC29370566C8
depends:        exportfs
vermagic:       2.6.32-642.6.2.el6.x86_64 SMP mod_unload modversions

Let me clarify:

I am not asking for advice in resolving the performance issue in this question. I'm only asking how to determine whether the XFS fix as described in the linked presentation is in the currently running XFS filesystem or not.

rrauenza
  • 555
  • 3
  • 16
  • Please describe this I/O workload in detail, or even better a fs_mark or similar script to reproduce something similar. – John Mahowald Jun 24 '19 at 22:06
  • @JohnMahowald Thank you for the offer, however this question isn't about how to diagnose or even fix the performance issue. – rrauenza Jun 24 '19 at 22:14

1 Answers1

1

The algorithm change cited as solving those XFS metadata problems is delayed logging, both in that 2012 linux.conf.au slide deck and the LWN write up of it.

Commit history of the documentation shows that the experimental flag was removed in 5d0af85. As this was circa October 2010, Linux 2.6.37:

xfs: remove experimental tag from the delaylog option

We promised to do this for 2.6.37, and the code looks stable enough to keep that promise.

So no, it is not in 2.6.32. I'm not entirely sure if Red Hat backported it, but I doubt it, seems like a major change.

Focus your efforts on upgrading the kernel. As EL6 has 16 months left of security updates, do that with an OS upgrade. Newer kernels or switching file systems is possible with EL6, but it changes your procedures when you should be upgrading.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Oddly, the mount options when looking at /proc/mounts includes delaylog. I wonder if RedHat *did* back port it. – rrauenza Jun 24 '19 at 21:52
  • Upgrading is not really relevant to my question right now -- we're trying to root cause a particular issue before making recommendations to remedy. – rrauenza Jun 24 '19 at 21:53
  • Then test your workload with other kernel versions or file systems on EL6. If you wish to stay with what Red Hat releases, there is only so many options, like switching to ext4. – John Mahowald Jun 24 '19 at 22:04