Bugzilla – Bug 385
xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c
Last modified: 2008-12-27 03:30:34 CST
[ i sent this to the linux-xfs ml, but i decided to file a bug now, because it is still not unresolved - as i thought before ] a few days ago i had to reboot the machine and i thought i could upgrade to a more recent kernel. i don't know if the following issue is related to this upgrade but as of now i can't mount my xfs fs any more. the hing is, i'm using loop-aes too and so xfs is on the loop device only: $ losetup -F /dev/loop7 Password: $ losetup -a /dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key $ mount -t xfs /dev/loop7 /data/Storage/ mount: wrong fs type, bad option, bad superblock on /dev/loop7, or too many mounted file systems so i've checked with "xfs_check -v /dev/loop7", because without "-v" the xfs_check returned no output (errorcode 0, so i assume no errors occured). the output of "xfs_check -v" is saved in http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/xfs_check-loop7.log.bz2 (will be available after the bzip2 finished, it's pretty large...) xfs_repair did (sorry, long) -------------------------- root@sheep:~# xfs_repair -v /dev/loop7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - 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 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 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 / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done -------------------------- this showed up once in the syslog too: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c XFS unmount got error 16 linvfs_put_super: vfsp/0xc324d260 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... and this is shown after an (unseccessful) mount: XFS: Filesystem loop7 has duplicate UUID - can't mount after some RTFM i've read http://oss.sgi.com/archives/linux-xfs/2004-02/msg00172.html and i could mount the thing with -o nouuid. after generating a new UUID, unmounting still gives: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c Filesystem "loop7": I/O Error Detected. Shutting down filesystem: loop7 Please umount the filesystem, and rectify the problem(s) but mount (without -o nouuid) gives: XFS mounting filesystem loop7 Ending clean XFS mount for filesystem: loop7 this is all on debian/unstable (i386), xfsprogs-2.6.20. do you need more infos about this things? xfsdump or sth. like this? perhaps someone can give me a hint here what to do next. thanks, Christian.
can you look at bug 388... maybe this is the same thing. what's the backing store for your loopback file? Is it lvm or md?
hm, do you really mean #388? it's about raid5 and "variable length transfers" and there is no error message of the corruptions at all (but a patch?) but i've looked at the bugs #376, #375, #321, #296, #272, #247 but all these xfs_force_shutdown were called from fs/xfs/xfs_trans.c, xfs_bmap.c and xfs_trans_cancel while this here was called from fs/xfs/xfs_rw.c. i did not find these types of xfs_force_shutdown's on the net either. the backing store for the loopback-device is a scsi-disk partition: $ losetup -a /dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key the kernel said furthermore: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c Filesystem "loop7": I/O Error Detected. Shutting down filesystem: loop7 hm, i thought, "i/o errors", could be hardware related then but it seemed unlikely, because sdb2+sdb3 are both in heavy use too, no errors, but not loop mounted too. badblocks showed no errors. i've reformatted loop7 (sdb1) with xfs then, but the errors were still there. right now i have to admit that the device is now formatted with another fs. (erm, it's reiserfs now. i've tried reiserfs some years ago, with no luck and wanted to give it another shot. but i can continue testing with xfs+loop-aes too, if it helps). thank you for your concern, Christian.
Yes, I did mean 388 but if your underlying device is just a simple scsi drive, then it's not related. -Eric
Looks like another of the dirty transaction shutdowns Dave has fixed a while ago.