[Top] [All Lists]

[Bug 186] xfs_force_shutdown on a lvm device

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 186] xfs_force_shutdown on a lvm device
From: bugzilla-daemon@xxxxxxxxxxx
Date: Sat, 26 Oct 2002 17:04:55 -0700
Sender: linux-xfs-bounce@xxxxxxxxxxx

------- 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.

<Prev in Thread] Current Thread [Next in Thread>