From: Marko Weber|8000 <weber@zbfmail.de>
To: Xfs <xfs@oss.sgi.com>
Subject: Re: unclean shutdown of usb hdd destroyed xfs partially
Date: Tue, 16 Sep 2014 23:27:45 +0200 [thread overview]
Message-ID: <330c89398cb4eef9b7289c1ffef8bcc3@zbfmail.de> (raw)
In-Reply-To: <20140913220916.GC4267@dastard>
Am 2014-09-14 00:09, schrieb Dave Chinner:
> On Sat, Sep 13, 2014 at 04:36:59PM +0200, Marko Weber|8000 wrote:
>>
>> an output of xfs_repair -v -L /dev/sde1
> ...
>>
>> # xfs_repair -v -L /dev/sde1
>
> What version?
first it was 3.1.10
later like posted 3.2.1
>
>> Phase 1 - Superblock finden und überprüfen...
>> - Berichts-Prozess in Abständen von 15 Minutes
>> - Block-Zwischenspeichergröße ist auf 1487792 Einträge gesetzt
>> Phase 2 - ein internes Protokoll benutzen
>> - Null-Protokoll...
>> zero_log: head block 40 tail block 40
>> - freier Speicher und Inode-Karten des Dateisystems werden
>> gescannt...
>> bad magic numberbad magic numberbad magic number
> ....
>> falscher on-disk-Superblock 12 - falsche Magische Nummer
>> Metadata corruption detected at block
>> 0x20bf8e50/0x1000primäre/sekundärer Superblock-12-Konflikt -
>> AG-Superblock-Geometrie-Info hat einen Konflikt mit der
>> Dateisystem-Geometrie
>> flasche magische # 0x0 für agf 12
>> falsche Version # 0 für agf 12
>>
>> Metadata corruption detected at block 0x417f1c90/0x1000
>> falscher on-disk-Superblock 6 - falsche Magische Nummer
>> primäre/sekundärer Superblock-6-Konflikt -
>> AG-Superblock-Geometrie-Info hat einen Konflikt mit der
>> Dateisystem-Geometrie
>> falscher on-disk-Superblock 3 - falsche Magische Nummer
>> ungenutzten Anteil des »sekundär«-Superblocks nullen (AG #6)
>> Metadata corruption detected at block 0x57542610/0x1000
>> falsche Sequenz # 0 für agf 12
>> Metadata corruption detected at block
>> 0x7813b450/0x1000Speicherzugriffsfehler
>
> I don't read german(?) but that looks like many AG header block
> have been overwritten with zeros (0 magic number, 0 sequence #, 0
> length, etc) and so even if we can repair the filesystem, I'd
> suggest that you need to verify that the data in every file in the
> filesystem is correct.
>
> Is that as far as xfs_repair got? If so, it would have appeared to
> crash. Can you run the lastest version inside gdb to get a stack
> trace when it dies? Or, alternatively, provide a metadump for one of
> us to look at more closely?
yes, this is as far xfs_repair got it.
what is ment 'run latest version in gdb?' gnudebugger? how do i do that?
console example needed.
and how do i do the metadump?
thank you
marko
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-09-16 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-13 14:33 unclean shutdown of usb hdd destroyed xfs partially Marko Weber|8000
2014-09-13 14:36 ` Marko Weber|8000
2014-09-13 22:09 ` Dave Chinner
2014-09-16 21:27 ` Marko Weber|8000 [this message]
2014-09-16 22:10 ` Dave Chinner
2014-09-13 14:43 ` Carlos E. R.
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=330c89398cb4eef9b7289c1ffef8bcc3@zbfmail.de \
--to=weber@zbfmail.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.