Date:   Sun, 3 Sep 2000 23:06:45 -0700 (PDT)
Message-Id: <200009040606.XAA01249@info.engr.sgi.com>
webPV:  wobbly.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (nathans@engr.sgi.com)
Subject: ADD 800293 - repair can corrupt directories
To:     nathans@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800293

 Status : open                         Priority : 2                         
 Assigned Engineer : nathans           Submitter : nathans                  
*Modified User : nathans              *Modified User Domain : engr          
*Description :
Test 031 reproduces this one - it runs mkfs and then repairs
numerous different combinations of directory version and
directory size ... repair seems to get itself into trouble
without even mounting these filesystems (created using mkfs
prototype files).

To exercise this bug (use the sim mkfs/repair binaries, cos
we seem to trip an assert in libxfs-mkfs before completing):
$ cd cmd/xfs/sim
$ make

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: nathans@engr (BugWorks)
Date: Sep 03 2000 11:06:44PM
==========================


OK, so I've investigated the first part of this bug now, i.e. the
"rebuilding directory inode 128" message.  It turns out that this
is simply the way its designed to work... this message comes about
as a side effect of us deleting the existing lost+found entry in
the root directory (inode 128 in this QA test), and that message
is printed unconditionally later when we find we need to fix some
directory.  This is the case for all non-shortform v2 directories,
and is not a real problem after all.

Onto the "# of bmap records" error message next...