xfs
[Top] [All Lists]

Re: unclean shutdown of usb hdd destroyed xfs partially

To: weber@xxxxxxxxxx
Subject: Re: unclean shutdown of usb hdd destroyed xfs partially
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 14 Sep 2014 08:09:16 +1000
Cc: Xfs <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <082ebd288523ee6155b66debade2a775@xxxxxxxxxx>
References: <3999c95c0dc7ebfdfbb2853a6d13f7dc@xxxxxxxxxx> <082ebd288523ee6155b66debade2a775@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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?

> 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?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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