------- Additional Comments From c.pascoe@xxxxxxxxxxxxxx 2002-10-26 17:04
I'd hazard a guess that Juri's problem is the same as the one that Christian and
I are seeing in this bug. I also believe it is the same as Tim is experiencing
in bug 187.
It looks as though the common factor is we all have a XFS filesystem exported
via NFS. I've checked with Tim and he is exporting a filesystem via NFS on the
system he reported the problems for.
Regarding it not being reproducable - you're in luck. I can reproduce this
problem, usually within 30 minutes or so, by running fsstress on an XFS
filesystem exported via NFS - across the NFS mount. I always get a
xfs_force_shutdown generated in xfs_trans.c (which corresponds with a dirty
transaction being aborted). I will upload the scripts that I use for my tests
briefly - they're nothing fancy, but do contain a random number seed that seems
to cause everything to reliably fail for me.
Things I've eliminated:
* LVM - I get the errors using a plain block device;
* compiler version - I have built with kgcc (egcs 2.91.66) and RedHat
gcc 2.96-98; both report the error
* SMP - a CONFIG_SMP=n build still fails
* HIGHMEM - Tim's system is SMP with 512MB RAM, and fails
* NFS v3/v2 - I have mounted the filesystem with both versions 2 and 3;
I receive the error with both.
The XFS version I am testing now is:
SGI XFS CVS-10/26/02:05 with ACLs, quota, no debug enabled
however, the problem existed at 3/10/2002.
I plan to step back through time and see if I can track down when the problem
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.