http://bugzilla.kernel.org/show_bug.cgi?id=11653
david@xxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|xfs-masters@xxxxxxxxxxx |david@xxxxxxxxxxxxx
Status|NEW |ASSIGNED
------- Comment #4 from david@xxxxxxxxxxxxx 2008-09-27 18:26 -------
Joshua,
I might as well close this bug now, what you've done will have removed
any trace of the problem that caused the filesystem to shut down.
In future:
- the NFS server holds references to the filesystem; you need to
unexport it or shut down the NFS server to be able to unmount it.
- xfs_check or xfs_repair can't correctly until the journal has been
replayed. Hence after unmounting, you need to remount it to get
journal replay to occur, then unmount it again and run xfs_check
- xfs_repair -L is _dangerous_. It will cause transactions that can
be safely replayed to be tossed away, and guarantees that xfs_repair
finds inconsistencies in the filesystem. This typically hides whatever
problem caused the shutdown - it is a repair method that should only
be used when the journal is corrupted.
If you don't know how to handle the failure properly - ask us. We can
tell you exactly what you need to do to quickly recover the filesystem
and to do so in a manner that is also helpful to us in tracking down
the bug that caused the shutdown.
That being said, if it was a corrupted inode btree block, then we've probably
just fixed the last known occurrence of this and it should be available in
2.6.27-rc8....
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.
|