xfs
[Top] [All Lists]

ADD 800489 - panic in umount after repair

To: nb@xxxxxxx
Subject: ADD 800489 - panic in umount after repair
From: pv@xxxxxxxxxxxxxxxxxxxxxx (dxm@xxxxxxxxxxxxxxxxx)
Date: Tue, 29 Aug 2000 20:25:03 -0700 (PDT)
Cc: linux-xfs@xxxxxxxxxxx
Reply-to: sgi.bugs.xfs@xxxxxxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
 Submitter : nathans                   Status : open                        
 Assigned Engineer : nb                Priority : 1                         
*Modified Date : 08/29/00             *Modified User : dxm                  
*Modified User Domain : melbourne     *Description :
After deliberate corruption followed by repair, we seem to trip
an assert in the unmount code.  I've just checked in a QA test
which can reproduce this (030), but it doesn't reliably reproduce
it (I've seen it only twice out of six/seven iterations).

My current test environment is using top-of-tree libxfs-mkfs and a
libsim-repair installed to / (I'm trying to verify the old repair
before checking in a bunch of changes to it).  The kernel I'm using
is a bit dated too (built 18 August) - might be part of the problem.
I'll update that later today & see if this still happens.

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: daniel moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Aug 29 2000 08:25:03PM
[pvnews version: 1.71]
==========================

 => After deliberate corruption followed by repair, we seem to trip
 => an assert in the unmount code.  I've just checked in a QA test
 => which can reproduce this (030), but it doesn't reliably reproduce
 => it (I've seen it only twice out of six/seven iterations).
 => 
 => My current test environment is using top-of-tree libxfs-mkfs and a
 => libsim-repair installed to / (I'm trying to verify the old repair
 => before checking in a bunch of changes to it).  The kernel I'm using
 => is a bit dated too (built 18 August) - might be part of the problem.
 => I'll update that later today & see if this still happens.

 => XFS assertion failed: i < xfs_uuidtab_size, file: xfs_mount.c, line: 1766
 => kernel BUG at xfs_debug.c:50!

That assertion would be tripped if you filled the uuid table up.
XFS used to leave behind entries in the uuid table on failed mounts
(pv 799752) but my TAKE on 23 August should have fixed this.

Try it out with that change and let me know if you still have
problems.

-----------------------------------------------------
 Daniel Moore                  dxm@xxxxxxx
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>
  • ADD 800489 - panic in umount after repair, dxm@xxxxxxxxxxxxxxxxx <=