Yes I am running xfs_fsr with the -v flag. But I'm not 100% sure if the
log was truncated since it resides in /var which locked up. Here are the
last log entries before the oopses:
If you've got the inode numbers, then your running with the verbose
flag set? Do you still have the logs for those inodes that it hung
ino=134269708 (this inode was /var/log/xfs_fsr.log)
ino=277040401 (this inode was /var/spool/imap/x/user/xxxx/cyrus.cache)
I can pin down those things at the moment:
- Both times it was a "hot" file - in one case a logfile, in the other
case a database file.
- Usually it should say "file busy" and continue but sometimes it
doesn't and just hangs the filesystem + oopses the kernel.
- It happens randomly, if i rerun xfs_fsr after the hang it usually goes
over the "problem" file without a hickup.
- On /var/log/xfs_fsr.log it hung even though the (+f) chattr was set.
Yes, usually it says "marked as don't defrag, ignoring" but this one
time it hung.
xfs_fsr doesn't do directory traversals to find files for defrag -
it uses more efficient bulkstat+open-by-handle method to visit every
inode in the filesystem once. As a result, it will still open inodes
that have the nodefrag flag set on them, but will then ignore them once
it finds the flag is set.
A trace would tell us which one it was....
Will see that i can get another one.