Perhaps a use after free or a reference counting problem. Thanks for reporting it. Which no-one noticed was related to XFS (not in the subject line) and so most people (like me) would have simply del
[snip] thanks my source directory was an openwrt trunk (svn co svn://svn.openwrt.org/openwrt/trunk/) which I had done a compile on, I went to delete it (just about every time it would cause this prob
So you're having primary a NFS workload, right? Andrew had some dmesg output in bugzilla (please send this stuff to the list instead of hiding it in bugzilla if possible, BTW) that looks quite intere
Hi I had a partition about 400G of xfs (lvm on a raid6 device) with source tree of openwrt trunk on the partition (~200-300M of data and lots of files - current tree ~ 40000 ) I have a VM (Virtualbox
Resembles me of trouble I've recently seen on some of the machines I maintain after updating from 2.6.27.11 to 2.6.29.[2,3], serving a few dozend LTSP (diskless so-called thin-clients) root filesyste
Disregard - I just realized that the above statement is untrue, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! --
Sorry guys, still haven't been able to track it down. Any chance one of you could run with CONFIG_XFS_DEBUG enabled and see if it trips over any of the asserts?
Hi Christoph, I'm running these systems as application servers for schools - with diskless clients. Therefore it's highly impractical to to any debugging during the week (they're going to kill me ;-)
Hi Christoph, "Say N unless you are an XFS developer, or you play one on TV." Very nice ;-) I'm have to regret that I'm neither an XFS developer nor do I pretend to be one. Yet, as I understand, I sh
Hi Christoph, Sorry guys, still haven't been able to track it down. Any chance one of you could run with CONFIG_XFS_DEBUG enabled and see if it trips over any of the asserts? "Say N unless you are a
That warning is what really makes me freak out, as it really, really shouldn't happen. Can you see if it gives any additional useful output with the patch below? Index: linux-2.6/fs/exportfs/expfs.c
reconnect_path: npd != pd reconnect_path: npd != pd reconnect_path: npd != pd .... on a thorougly checked filesystem, plus the NFS service ceasing to serve clients. Obviously this is not covered by t
Find here a package containing the respective syslog section plus a (I think so) non-obfuscated metadump (in order to corellate to the directory names to the syslog): http://foxtrot.mgras.net/static/
So we're getting duplicate in-core inodes for the same inode number somehow. That also explains the earlier radix-tree bug because we would delete the node from the radix tree when the first instance
http://foxtrot.mgras.net/static/messages-20090607.2.bz2 I'm sorry but I'll have to boot the system using the previous kernel, again, as people expect to have their system in a reliably working state
Next 'maintenance window' ;-) starts wednesday evening. Please advise if you'd like me to perform further tests, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -
For now I'd love you to test the locking patch I sent you in my last mail. In the meantime I still fail to reproduce anything like your problem locally. I know we do need to reboot the machine or une