> It sounds to me like your filesystem is indeed damaged. I
> suggest repairing
> it with xfs_repair.
---
It's my root file system, it's a bit hard to unmount, but
xfs_check has no output and xfs_repair seems to just show progress:
# xfs_repair -nf /dev/sda1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem starting at / ...
- 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.
---
> You will probably get the filesystem shutdown when using tar as well.
> The problem crops up because the moment it tries to read the file it
> immediatly triggers a filesystem corruption error state. So it (probably)
> won't matter
> if you would use tar or xfsdump, it would barf anyhow.
---
File system seems fine...It's been used without noticable
problems since problem appeared in _October_. Wasn't real concerned
since rootfs mostly contains stuff that doesn't change much (distro
and config files, configs backed up).
It's just xfs_dump that dumps...(or doesn't). Wish it wasn't
so rude as to just assume my FS is bad and unmount it -- as everything
else seems fine.
Approx 187,000 names ("find / -xdev|wc") with over
10,000 dirs, /dev/sda3 tot=5.5G used=4.1G avail=1.5G 75% /
-l
|