public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Federico Sevilla III <jijo@fs3.ph>
To: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c
Date: Thu, 26 Feb 2009 02:47:48 +0800	[thread overview]
Message-ID: <1235587668.30386.3.camel@disciplina.fs3.ph> (raw)
In-Reply-To: <1235556051.17569.4.camel@disciplina.fs3.ph>


[-- Attachment #1.1.1: Type: text/plain, Size: 1256 bytes --]

On Wed, 2009-02-25 at 18:00 +0800, Federico Sevilla III wrote:
> On Wed, 2009-02-25 at 09:46 +1100, Dave Chinner wrote:
> > On Tue, Feb 24, 2009 at 09:04:21PM +0800, Federico Sevilla III wrote:
> 
> > >         attempt to access beyond end of device
> > >         sda7: rw=0, want=154858897362229008, limit=3885978852
> > >         I/O error in filesystem ("sda7") meta-data dev sda7 block 0x2262b58bf959708       ("xfs_trans_read_buf") error 5 buf count 4096
> > 
> > A corrupted extent pointer of some kind. xfs_repair should have
> > found this. Can you run xfs_repair again? If it doesn't find
> > anything, please upgrade xfs_repair to the latest version and
> > try again.

I have attached the output of xfs_repair. You are correct, it did find
errors with the file system, and repaired them. I don't know why this
wasn't caught the first time, but I guess the lesson learned here is to
re-run xfs_repair until it finds no further errors.

Does the output of xfs_repair help give you an idea of what could have
been the root cause of the crash? (I know it's a long shot, but maybe
you recognize a pattern in the messages.)

Thank you very much.

Cheers!

-- 
Federico Sevilla III
F S 3 Consulting Inc.
http://www.fs3.ph

[-- Attachment #1.1.2: xfs_repair_sda7.log --]
[-- Type: text/x-log, Size: 2588 bytes --]

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
bad bmap btree ptr 0xc4c025347495f41 in ino 536960951
bad data fork in inode 536960951
cleared inode 536960951
        - 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
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
entry "in_out of INK_LO_BG.xls" at block 0 offset 2352 in directory inode 537005595 references free inode 536960951
	clearing inode number in entry at offset 2352...
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - agno = 17
        - agno = 18
        - agno = 19
        - agno = 20
        - agno = 21
        - agno = 22
        - agno = 23
        - agno = 24
        - agno = 25
        - agno = 26
        - agno = 27
        - agno = 28
        - agno = 29
        - agno = 30
        - agno = 31
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
bad hash table for directory inode 537005595 (no data entry): rebuilding
rebuilding directory inode 537005595
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2009-02-25 18:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 13:04 xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Federico Sevilla III
2009-02-24 22:46 ` Dave Chinner
2009-02-25 10:00   ` Federico Sevilla III
2009-02-25 11:51     ` Michael Monnerie
2009-02-25 18:47     ` Federico Sevilla III [this message]
     [not found] <B3EDBE0F860AF74BAA82EF17A7CDEDC660BE05A3@svits26.main.ad.rit.edu>
2007-12-21  2:01 ` Jay Sullivan
2008-01-03 15:55   ` Jay Sullivan
2008-08-04 16:55   ` Richard Freeman
  -- strict thread matches above, loose matches on Subject: below --
2007-11-02  2:08 Jay Sullivan
2007-11-02  5:18 ` David Chinner
2007-11-01 20:06 Jay Sullivan
2007-11-02  2:14 ` Eric Sandeen
2007-11-02  2:22   ` Jay Sullivan
2007-11-02  2:30     ` Eric Sandeen
2007-11-02  9:07       ` Ralf Gross
2007-11-02 16:10         ` Eric Sandeen
2007-11-02 14:00       ` Jay Sullivan
2007-11-02 14:49         ` Jay Sullivan
2007-11-14 15:05           ` Jay Sullivan
2007-11-15  3:26             ` Eric Sandeen
2007-11-02  4:37   ` Timothy Shimmin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1235587668.30386.3.camel@disciplina.fs3.ph \
    --to=jijo@fs3.ph \
    --cc=linux-xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox