Hi David,
sorry for the late response:
On Wed, 27 Apr 2011 at 20:28, Dave Chinner wrote:
> hmmmm. Speaking of which - have you changed any of the XFS tunables
> in /proc/sys/fs/xfs/ on your machine (specifically
> xfssyncd_centisecs)?
No, I did not change anything underneath /proc/sys/fs/xfs.
> Not easy because there are tree-wide changes that need to be
> preserved (e.g. block layer plugging changes) while others around it
> would need to be reverted....
Yeah, I noticed. I wanted to do something like this:
$ for c in `git log --pretty=oneline --no-merges v2.6.38..v2.6.39-rc2 fs/xfs | awk '{print $1}'`; do
git revert $c
done
...but this broke on the 1st or 2nd commit because of unresolved changes.
Now I'm in the middle of another bisect attempt, trying to reproduce but
Im getting (probably totally unrelated) warnings here:
BUG: sleeping function called from invalid context at /usr/local/src/linux-2.6-git/drivers/ide/ide-io.c:447
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
INFO: lockdep is turned off.
[...]
> Can you check if there are any blocked tasks nearing OOM (i.e. "echo
> w > /proc/sysrq-trigger") so we can see if XFS inode reclaim is
> stuck somewhere?
In one instance when I mounted with "noatime", no log messages made it to
the disk, but I could see "hung tasks":
http://nerdbynature.de/bits/2.6.39-rc4/oom/oom-6.JPG
I will try sysrq-w later on.
FWIW, a regression bug has been opened:
https://bugzilla.kernel.org/show_bug.cgi?id=34012
Thanks,
Christian.
--
BOFH excuse #284:
Electrons on a bender
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
