[Bug 385] New: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c

[bugzilla-daemon@xxxxxxxxxxx]

http://oss.sgi.com/bugzilla/show_bug.cgi?id=385

           Summary: xfs_force_shutdown(loop7,0x1) called from line 353 of
                    file fs/xfs/xfs_rw.c
           Product: Linux XFS
           Version: Current
          Platform: IA32
               URL: http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: High
         Component: XFS kernel code
        AssignedTo: xfs-master@xxxxxxxxxxx
        ReportedBy: evilninja@xxxxxxx


[ 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.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.