From: Eric Sandeen <sandeen@sandeen.net>
To: George Barnett <george@alink.co.za>
Cc: xfs@oss.sgi.com
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
Date: Tue, 03 Feb 2009 19:46:11 -0600 [thread overview]
Message-ID: <4988F363.1070708@sandeen.net> (raw)
In-Reply-To: <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za>
George Barnett wrote:
> On 04/02/2009, at 12:28 PM, Eric Sandeen wrote:
>
>> George Barnett wrote:
>>> Hi,
>>>
>>> I'm seeing the following errors:
>>>
>>> [822153.422851] Filesystem "md2": XFS internal error xfs_da_do_buf(2)
>>> at line 2107 of file /build/buildd/linux-2.6.27/fs/xfs/
>> we really should make that more informative.
>>
>> What it means is that you read a piece of metadata that did not match
>> any of the metadata magic numbers.
>>
>> hard to say whether it might be an xfs bug I think; this does come up
>> occasionally though and it'd at least be nice to print more details on
>> the error (what the magic *was*, what block, etc)
>>
>> Do you happen to have the repair output?
>>
>> Did your md raid lose power w/ write cache enabled?
>
> Hi Eric,
>
> Thanks for your response. The system did not lose power. This
> failure just "happens". I have a cronjob which rsync's /data to a
> spare drive that's not on raid. It seems that is enough to cause this
> failure.
>
> Fortunately, I still have the xfs_repair output in my term buffer:
>
> root@slut:/# xfs_repair /dev/md2
> 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
> bad magic number 0x0 on inode 18042
> bad version number 0x0 on inode 18042
> bad magic number 0x0 on inode 18043
> bad version number 0x0 on inode 18043
> bad magic number 0x0 on inode 18044
> bad version number 0x0 on inode 18044
> bad magic number 0x0 on inode 18045
> bad version number 0x0 on inode 18045
> bad magic number 0x0 on inode 18046
> bad version number 0x0 on inode 18046
> bad magic number 0x0 on inode 18047
> bad version number 0x0 on inode 18047
> bad directory block magic # 0 in block 0 for directory inode 18000
Interesting that all the bad magic numbers were 0... not sure what to
make of that, offhand, I'm afraid...
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-02-04 1:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 0:32 XFS corruption on ubuntu 2.6.27-9-server George Barnett
2009-02-04 1:28 ` Eric Sandeen
2009-02-04 1:34 ` George Barnett
2009-02-04 1:46 ` Eric Sandeen [this message]
2009-02-04 1:53 ` George Barnett
2009-02-04 2:05 ` Eric Sandeen
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=4988F363.1070708@sandeen.net \
--to=sandeen@sandeen.net \
--cc=george@alink.co.za \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.