View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801241
Status : open Priority : 1
Assigned Engineer : dxm Submitter : ivanr
*Modified User : dxm *Modified User Domain : engr
*Description :
QA for xfsdump/xfsrestore revealed that it is possible for
xfsdump to cause filesystem corruption. The test involves
creating a filesystem, creating a whole buncha files, xfsdumping
them to a file somewhere, then removing all the files. xfs_check
reports lots of inodes with zero link counts, etc. It's probably
due to xfsdump using bulkstat on the entire fs.
The following is a script which will reliably (at least on
bruce.melbourne) produce the error. Run it in cmd/xfs/stress -
it needs the src/fill program, and make sure you fix the
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Sep 14 2000 07:03:07PM
==========================
*** comment from linux-xfs ***
Subject: Should open_by_inode have a special dentry ops?
Date: Wed, 13 Sep 2000 20:24:32 -0500 (CDT) (Thu 12:24 EST)
From: William L Jones <jones@xxxxxxxxxxxxxxxxxx>
Shouldn't open_by_inode have a dentry_operations table like the one found in
xfs_iops.c?
I think it should. This may be the source of the reference leak that was noticed
after using xfxdump.
If it does, doesn't that indicate that their may be problems exporting a xfs
file system
in linux. NFS also creates its own dentries from inodes gained by iget?
Bill Jones
*** comment from linux-xfs ***
Subject: Re: Should open_by_inode have a special dentry ops?
Date: Thu, 14 Sep 2000 09:51:58 -0500 (Fri 01:51 EST)
From: Steve Lord <lord@xxxxxxx>
You may have a point here, if we do not go into the vnode layer when dropping
the
reference count it will fail to call the xfs inactive code.
Steve
***
I've got a fix for this bug based on these two posts, and will
hopefully slip it into the beta release.
|