xfs
[Top] [All Lists]

Re: XFS shutdown with 1.3.0

To: "Nathan Scott" <nathans@xxxxxxx>
Subject: Re: XFS shutdown with 1.3.0
From: "Simon Matter" <simon.matter@xxxxxxxxxxxxxxxx>
Date: Tue, 2 Sep 2003 13:14:23 +0200 (CEST)
Cc: linux-xfs@xxxxxxxxxxx
Importance: Normal
In-reply-to: <20030902071613.GB1378@frodo>
References: <41782.213.173.165.140.1062330069.squirrel@xxxxxxxxxxxxxxxxxxxxxxx> <20030902071613.GB1378@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: SquirrelMail/1.4.1
>> xfs_inotobp: xfs_imap()  returned an error 22 on md(9,8).  Returning
>> error.
>> xfs_iunlink_remove: xfs_inotobp()  returned an error 22 on md(9,8).
>> Returning error.
>> xfs_inactive:   xfs_ifree() returned an error = 22 on md(9,8)
>> xfs_force_shutdown(md(9,8),0x1) called from line 1846 of file
>> xfs_vnodeops.c.  Return address = 0xd08bd8c6
>> Filesystem "md(9,8)": I/O Error Detected.  Shutting down filesystem:
>> md(9,8)
>> Please umount the filesystem, and rectify the problem(s)
>
> Hmmm - seen a couple of these reports now, unfortunately I haven't
> come across it myself yet.  Someone else has a bugzilla bug open,
> it seems to be really difficult to trigger this one.
>

The only thing I did in that moment was removing a file of ~1.5G size with
rm file. Although there were some files open on this filesystem via NFS,
there was absolutely no activity.

>>
>> [root@xxl root]# xfs_check /dev/md8
>> xfs_check: warning - cannot get sector size from block device /dev/md8:
>> Invalid argument
> ^^^^^^^^^^^^^^^^^^^
> this is where those bogus md "ictls" are coming from, btw.  Its
> fixed in more recent kernels, you can search lkml archives for
> recent Neil Brown patches and find the fix (its some missing code
> in md, and is harmless here).

I've seen this since long time so I didn't worry about it.

>
>> agf_freeblks 22053, counted 30629 in ag 6
>> agi_freecount 332, counted 331 in ag 153
>>
>> [root@xxl root]# xfs_repair -n -l /dev/md9 /dev/md8
>
> Running xfs_repair without -n might help in this case to fix sufficient
> data on the first run that subsequent runs don't dump core. :|

Now that I took a recent backup of the most important data, I'll try this
next :)

>
> The gdb trace from xfs_repair will provide more clues here too.
>
>> xfs_repair: warning - cannot get sector size from block device /dev/md8:
>> Invalid argument
>> xfs_repair: warning - cannot get sector size from block device /dev/md9:
>> Invalid argument
>> Phase 1 - find and verify superblock...
>> sb root inode value 128 inconsistent with calculated value 512
>> would reset superblock root inode pointer to 512
>
> Wierd.  Is this a 4K blocksize filesystem?  Do you have xfs_info
> output handy?  taa.

[root@xxl root]# xfs_info /home
meta-data=/home                  isize=256    agcount=160, agsize=262144 blks
         =                       sectsz=512
data     =                       bsize=4096   blocks=41889120, imaxpct=25
         =                       sunit=32     swidth=96 blks, unwritten=0
naming   =version 2              bsize=4096
log      =external               bsize=4096   blocks=25600, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=393216 blocks=0, rtextents=0

IIRC I created the FS with some XFS 1.0.x version. The size was ~20G, I
have since grown it to ~170G.

>
>> sb realtime bitmap inode 129 inconsistent with calculated value 513
>> would reset superblock realtime bitmap ino pointer to 513
>> sb realtime summary inode 130 inconsistent with calculated value 514
>> would reset superblock realtime summary ino pointer to 514
>> Phase 2 - using external log on /dev/md9
>>         - scan filesystem freespace and inode maps...
>> root inode chunk not found
>> avl_insert: Warning! duplicate range [512,576]
>> add_inode - duplicate inode range
>> Phase 3 - for each AG...
>>         - scan (but don't clear) agi unlinked lists...
>>         - process known inodes and perform inode discovery...
>>         - agno = 0
>> bad .. entry in directory inode 128, points to self: would clear entry
>> data fork in inode 170 claims metadata block 32
>> bad data fork in inode 170
>> would have cleared inode 170
>> data fork in inode 171 claims metadata block 33
>> bad data fork in inode 171
>> would have cleared inode 171
>>         - agno = 1
>>         - agno = 2
>>         - agno = 3
>>         - agno = 4
>>         - agno = 5
>> <SNIP>
>>         - agno = 156
>>         - agno = 157
>>         - agno = 158
>>         - agno = 159
>>         - process newly discovered inodes...
>> Phase 4 - check for duplicate blocks...
>>         - setting up duplicate extent list...
>> Segmentation fault
>>
>> [root@xxl root]# xfs_repair -V
>> xfs_repair version 2.5.6
>>
>> I never considered the following a problem but wanted to mention it
>> anyways.
>> While running xfs_check and xfs_repair, I also get this in the logs:
>>
>> md: xfs_db(pid 9985) used obsolete MD ioctl, upgrade your software to
>> use
>> new ictls.
>
> This part at least is an md problem fixed in more recent kernels.
> The corruption is more concerning though, and unrelated.
>
> cheers.
>
> --
> Nathan
>


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