I had a RH 7.1 system (2.4.6-pre1-xfs) fail to boot properly, most
likely because I had swapped drives around. Well, it wasn't exactly a
failure, it was that irritating kudzu losing all hardware information.
It wanted to reconfigure every single device, it claimed it had never
seen them before. I rebooted and reset the drives, but it still claimed
the items were new.
But since I did not know with certainty that it really was the hard
drive placement (I've made this rearrangement before, it never lost its
memory of all devices before...and I mean everything), I tried running
xfs_repair. First I tried on a read-only single user mode, and it gave
the "fatal error --coudn't initialize XFS library". I rebooted to
another install on another drive that has XFS, and ran
xfs_repair...somewhat indicating maybe there was a problem. Here is the
output, some parts snipped that are uninteresting:
~# xfs_repair /dev/sda6
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
.......snip....
- agno = 30
- agno = 31
- agno = 32
- 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
......snip...
- agno = 30
- agno = 31
- agno = 32
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 ...
disconnected inode 1266147, moving to lost+found
Phase 7 - verify and correct link counts...
done
Now I rebooted back to the original drive partition, which works fine
after telling kudzu to shut up and not reconfigure all the devices and
to not prompt me again. Btw, the disconnected inode was empty, size 0.
But it appears that xfs_repair is broken on it, because running
xfs_repair -n claims it could not initialize the xfs library. The end of
an strace makes me believe xfs_repair with "-n" will still refuse to
look at a partition that is mounted:
open("/etc/mtab", O_RDONLY) = 3
brk(0x80d2000) = 0x80d2000
fstat64(3, {st_mode=S_IFREG|0644, st_size=150, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "/dev/sda6 / xfs rw 0 0\nnone /pro"..., 4096) = 150
read(3, "", 4096) = 0
write(2, "xfs_repair: /dev/sda6 contains a"..., 61xfs_repair: /dev/sda6
contains a writable mounted filesystem
) = 61
close(3) = 0
munmap(0x40018000, 4096) = 0
write(2, "\nfatal error -- ", 16
fatal error -- ) = 16
write(2, "couldn\'t initialize XFS library\n", 32couldn't initialize XFS
library
) = 32
_exit(1) = ?
Shouldn't xfs_repair allow me to at least attempt to see what it would
do with "-n"?
I noticed one other thing during the process that is definitely a bug,
but not necessarily xfs...it could be a mount bug. While in single user
mode, after remounting the partition read-only, it was falsely listed as
read/write when the mount command was run to see current mounts. I know
it was incorrect becase I tried intentionally to write to a file as a
test, and it correctly told me the file could not be saved because the
partition was read-only. The output of mount while in single user mode
and after sda6 was remounted read-only:
/dev/sda6 on / type xfs (rw)
none on /proc type proc (rw)
/dev/sda5 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
One more question related to this. Assuming my xfs_repair had not been
broken, that whatever caused it to be "unable to initialize xfs library"
had not occurred, and that I have the partition mounted read-only, is
this still supposed to disallow xfs_repair? Is it still a risk to
corruption if one runs xfs_repair on a read-only mounted partition?
FYI, none of this seems to have actually harmed anything in any way. I
suspect the one inode it unlinked during repair was there because when
kudzu came up and it started to setup hardware again, I gave it the
three finger salute (which should properly close things down, but
possibly it killed kudzu's version of an editor without closing).
D. Stimits, stimits@xxxxxxxxxx
|