[Top] [All Lists]


To: xfs@xxxxxxxxxxx
Subject: XFS internal error XFS_WANT_CORRUPTED_GOTO
From: Amit Sahrawat <amit.sahrawat83@xxxxxxxxx>
Date: Fri, 22 Jul 2011 10:22:13 +0530
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Toy9b6z+3UYW/z0LVgTyOgKe6wmK0/LS0TForLd778=; b=odclUlr7vwNSZeSIYWt9G8cYPrg5zLr5oWuK37G3mtX0Jvb8HID2d+YD7hJnIzE4lU sJL+knsh4HUdzxqSUdWCrXxTke6WleDlN8tlhPzsmOj3SepZOyY5/MSWblbS2JxPiKtx ucQrVNEBHpdBqtYuo6tXKJXXsxiztvhFhXae8=
Dear All,

Target : ARM

Recently I encountered a corruption on XFS for RC-3. While the
DIRECT-IO for a file was in operation (Write operation) there was a
power reset - Only one file at a time is being written to the disk
using DIO.. After reboot on mounting I just tried to remove the file
and encountered the below mentioned corruption.  The hard disk is not
able to mount after this, only after clearing logs (xfs_repair –L) –
disk is able to mount
XFS mounting filesystem sda1
XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1535 of file
fs/xfs/xfs_alloc.c.  Caller 0xc0152c04
[<c0023000>] (dump_backtrace+0x0/0x110) from [<c02dd680>] (dump_stack+0x18/0x1c)
 r6:00000000 r5:c0152c04 r4:00000075 r3:e3ec1c88
[<c02dd668>] (dump_stack+0x0/0x1c) from [<c0176bd0>]
[<c0176b84>] (xfs_error_report+0x0/0x5c) from [<c01510d4>]
[<c0150cd4>] (xfs_free_ag_extent+0x0/0x600) from [<c0152c04>]
[<c0152b78>] (xfs_free_extent+0x0/0xa4) from [<c015ffa8>]
 r7:e3ec1e10 r6:00000000 r5:e3737870 r4:e373e000
[<c015fea0>] (xfs_bmap_finish+0x0/0x194) from [<c017e840>]
[<c017e664>] (xfs_itruncate_finish+0x0/0x30c) from [<c0197dc8>]
[<c0197bbc>] (xfs_inactive+0x0/0x40c) from [<c01a3da0>]
 r9:e3ec0000 r8:c001f128 r7:00000000 r6:e4671a80 r5:c0312454
[<c01a3d50>] (xfs_fs_clear_inode+0x0/0x60) from [<c00bdd84>]
 r4:e4667420 r3:c01a3d50
[<c00bdcf8>] (clear_inode+0x0/0xe8) from [<c00be584>]
 r4:e4667420 r3:ffffffff
[<c00be4a8>] (generic_delete_inode+0x0/0x178) from [<c00be640>]
 r5:00000000 r4:e4667420
[<c00be620>] (generic_drop_inode+0x0/0x68) from [<c00bd368>] (iput+0x6c/0x7c)
 r4:e4667420 r3:c00be620
[<c00bd2fc>] (iput+0x0/0x7c) from [<c00b4c40>] (do_unlinkat+0xfc/0x154)
 r4:e4667420 r3:00000000
[<c00b4b44>] (do_unlinkat+0x0/0x154) from [<c00b4cb0>] (sys_unlink+0x18/0x1c)
 r7:0000000a r6:00000000 r5:00000000 r4:be90299b
[<c00b4c98>] (sys_unlink+0x0/0x1c) from [<c001ef80>] (ret_fast_syscall+0x0/0x30)
xfs_force_shutdown(sda1,0x8) called from line 4047 of file
fs/xfs/xfs_bmap.c.  Return address = 0xc015ffec
Filesystem "sda1": Corruption of in-memory data detected.  Shutting
down filesystem: sda1
Please umount the filesystem, and rectify the problem(s)

[root@localhost amits]# xfs_repair -n /dev/sdb1
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
data fork in ino 132 claims free block 115
data fork in ino 132 claims free block 116
        - 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 = 2
        - agno = 1
        - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
[root@localhost amits]#

Please find the logs for xfs_logprint at the time of issue attached.

If there was really corruption which is shown at the time of deletion
of file then why did the XFS file-system mounted? After checking the
blocks request being passed as free request – it showed that the at
the time of xfs_free_ag_extent() – the values from the tree fetched
are not correct – for blocks to the right of current file extent (may
be due to corruption) – is there anything written to xfs logs related
with this? So that at the mount time this thing can be taken care.

Please let me know in case more information is required for this.

Thanks & Regards,
Amit Sahrawat

Attachment: XFS-LogPrints-ForCorruptedFile
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>