Erm, the xfs_repair -n only prints out what it needs to fix, I read
somewhere that xfs_repair may make things worse?
What is the 'correct' fix?
On Thu, 20 Jul 2006, Justin Piszcz wrote:
Nasty!
- agno = 37
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem starting at / ...
free block 16777216 for directory inode 2684356622 bad nused
free block 16777216 for directory inode 2147485710 bad nused
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
p34:~#
I applied the "one line fix" - I should be ok now?
On Fri, 21 Jul 2006, Nathan Scott wrote:
On Thu, Jul 20, 2006 at 06:43:34PM -0400, Justin Piszcz wrote:
p34:~# xfs_check -v /dev/md3
xfs_check: out of memory
p34:~#
D'oh...
xfs_repair -n is another option, it has a cheaper (memory wise,
usually) checking algorithm.
As long as it mounted ok with the patched kernel, should one be ok?
Not necessarily, no - mount will only read the root inode.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|