Nathan Scott <nathans@xxxxxxxxxx> 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.)
|