Yes, as far as i can tell it's always a file that some process is
currently modifying. It happens ofter with some file unter /var/log
which syslog is currently modifying. I tried setting the "no-defrag"
flag via xfs_io's chattr on all log files but that didn't seem to help.
It seems that cyrus imapd is triggering this problem far more likely
than any other program. Some examples of files where it usually hangs:
Hi Michael - have you got any idea what the files are that are
hitting this? This failure is implying that the inode is still dirty
after syncing all the data. Is something trying to modify it while
XFS is trying to map it?
/var/spool/imap/x/user/xxxx/cyrus.cache (lsof -> cyrus)
/var/imap/db/log.xxxxxxx (lsof -> cyrus)
/var/log/xxx.log (lsof -> syslog)
I've also seen this happen occasionally before, but recently it started
to happen on about every second run of xfs_fsr. Because this is a
production system i've ceased using xfs_fsr for the moment. I've not
been able to reproduce it on others systems yet.
We've seen this occasionally in the past, but we've never been able
to reproduce it with any reliability. Hence any information you can
extract would certainly help us here.