Nathan Scott <[EMAIL PROTECTED]> writes: > On Tue, Sep 12, 2006 at 12:30:08AM +0200, Ferenc Wagner wrote: >> Package: xfsprogs >> Version: 2.8.11-1 >> Severity: normal >> >> I guess my problem is rooted in the 'well known' 2.6.17 error, or maybe >> not. Anyway, my experience under a current Sid system is that >> xfs_repair does not fix my filesystem. It does something, as the first >> two runs produced slightly different outputs, but the further runs did >> not. I've got similar problems on two filesystems: > > Try moving aside the contents of lost+found after the first run, > and see if the problems persist.
After renaming lost+found to l+f, xfs_repair didn't report any errors: => Phase 1 - find and verify superblock... => Phase 2 - using internal log => - zero log... => - scan filesystem freespace and inode maps... => - found root inode chunk => Phase 3 - for each AG... => - scan and clear agi unlinked lists... => - process known inodes and perform inode discovery... => - agno = 0 => - agno = 1 => - agno = 2 => - agno = 3 => - agno = 4 => - agno = 5 => - agno = 6 => - agno = 7 => - process newly discovered inodes... => Phase 4 - check for duplicate blocks... => - setting up duplicate extent list... => - clear lost+found (if it exists) ... => - check for inodes claiming duplicate blocks... => - agno = 0 => - agno = 1 => - agno = 2 => - agno = 3 => - agno = 4 => - agno = 5 => - agno = 6 => - agno = 7 => Phase 5 - rebuild AG headers and trees... => - reset superblock... => Phase 6 - check inode connectivity... => - resetting contents of realtime bitmap and summary inodes => - ensuring existence of lost+found directory => - traversing filesystem starting at / ... => - traversal finished ... => - traversing all unattached subtrees ... => - traversals finished ... => - moving disconnected inodes to lost+found ... => Phase 7 - verify and correct link counts... => done Still, xfs_check reported: => link count mismatch for inode 400254 (name ?), nlink 0, counted 2 => link count mismatch for inode 4239409 (name ?), nlink 0, counted 2 => link count mismatch for inode 8388736 (name ?), nlink 39, counted 38 Further runs of xfs_repair didn't bring any change. On the root filesystem the results are much the same, but xfs_check reports: => sb_ifree 3042, counted 3041 I read that xfs_check is being obsoleted in the future, but not sure which program to trust. Are my filesystems healthy or not? -- Thanks, Feri. (Please Cc: me, I'm not subscribed to the xfs mailing list.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
