All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Scott <nscott@aconex.com>
To: Martin Eisenhardt <martin.eisenhardt@wiai.uni-bamberg.de>
Cc: xfs@oss.sgi.com
Subject: Re: Unexpected XFS SB number 0x00000000
Date: Fri, 27 Apr 2007 08:57:19 +1000	[thread overview]
Message-ID: <1177628239.6273.374.camel@edge> (raw)
In-Reply-To: <200704262146.59921.martin.eisenhardt@wiai.uni-bamberg.de>

On Thu, 2007-04-26 at 21:46 +0200, Martin Eisenhardt wrote:
> Hello list(s),
> 
> I run XFS on a software raid on Linux 2.6.19. When I invoke xfs_db in 
> read-only mode, I get:
> 
> # xfs_db -r /dev/md0
> xfs_db: unexpected XFS SB magic number 0x00000000
> xfs_db: read failed: Invalid argument
> xfs_db: data size check failed
> Segmentation fault

I think this segfault is fixed in recent xfs_db versions.

> The system is still running, the filesystem seems to be fine (except for the 
> above): files are created, written, and deleted without any problem.
> 
> So, I have two questions:
> 
> * Is there a real problem, or might a quick reboot solve this?

It looks like a real problem to me - something has written zeroes to
the start of your partition, where the primary XFS superblock should
be.  If the filesystem is still mounted(?), I'd
a/ make a backup copy of anything/everything precious there
b/ try to get the incore copy of the XFS superblock flushed out (this
assumes still mounted) - creater a file & use sync(1) - you might get
lucky.

> * If there is a real problem with the file system: What steps do you recommend 
> to overcome this problem?
> * How safe is it to run xfs_check and xfs_repair?

If you really have zeroes over your primary superblock, xfs_repair
is your only option to fix that really (after unmounting).  You
wont get much joy from xfs_check, as its just a shell script wrapper
around the xfs_db "check" command.

> P.S.: Sorry for cross-posting, I just figure that maybe the XFS users on 
> non-linux systems might have a hint or two for me ... ;-)

Theres only one list (both addresses point to the same place).

cheers.

-- 
Nathan

  reply	other threads:[~2007-04-26 22:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-26 19:46 Unexpected XFS SB number 0x00000000 Martin Eisenhardt
2007-04-26 22:57 ` Nathan Scott [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-12-10 21:33 Chris
2007-12-10 22:40 ` Eric Sandeen
2007-12-11  1:06   ` Chris
2007-12-11  2:12     ` Eric Sandeen
2007-12-10 22:55 ` Justin Piszcz
2007-12-11 12:47 Chris

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=1177628239.6273.374.camel@edge \
    --to=nscott@aconex.com \
    --cc=martin.eisenhardt@wiai.uni-bamberg.de \
    --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.