unclean shutdown of usb hdd destroyed xfs partially

Discussion:

Marko Weber|8000

2014-09-13 14:33:21 UTC

hello dave hello list,

an unclean shutdown on of my boxes made the xfs partially corrupt.

i tried an xfs_repair with xfsprogs 3.1.10
then i read the corrupt data thread and tried it with 3.2.1 version of
xfsprogs.

when i mount the partition and do an ls -l i get:

# ls -l /mnt/temp
ls: Zugriff auf /mnt/temp/serien nicht möglich: Die Struktur muss
bereinigt werden
ls: Zugriff auf /mnt/temp/dokutv nicht möglich: Die Struktur muss
bereinigt werden
insgesamt 0
?????????? ? ? ? ? ? dokutv
drwxrwxr-x 33 weber mediatomb 1283 25. Aug 2013 movies
drwxrwxr-x 12 weber mediatomb 151 6. Aug 18:57 mp3
?????????? ? ? ? ? ? serien

the above lines with ls says "access not possible on serien and dokutv,
structure needs cleaning.

This is also after an xfs_repair -L /dev/sde1

is there any trick to get the data accessable again?

thanks for any hints or help

marko

Marko Weber|8000

2014-09-13 14:36:59 UTC

Permalink

an output of xfs_repair -v -L /dev/sde1

Post by Marko Weber|8000
hello dave hello list,
an unclean shutdown on of my boxes made the xfs partially corrupt.
i tried an xfs_repair with xfsprogs 3.1.10
then i read the corrupt data thread and tried it with 3.2.1 version of
xfsprogs.
# ls -l /mnt/temp
ls: Zugriff auf /mnt/temp/serien nicht möglich: Die Struktur muss
bereinigt werden
ls: Zugriff auf /mnt/temp/dokutv nicht möglich: Die Struktur muss
bereinigt werden
insgesamt 0
?????????? ? ? ? ? ? dokutv
drwxrwxr-x 33 weber mediatomb 1283 25. Aug 2013 movies
drwxrwxr-x 12 weber mediatomb 151 6. Aug 18:57 mp3
?????????? ? ? ? ? ? serien
the above lines with ls says "access not possible on serien and
dokutv, structure needs cleaning.
This is also after an xfs_repair -L /dev/sde1
is there any trick to get the data accessable again?
thanks for any hints or help
marko
_______________________________________________
xfs mailing list
http://oss.sgi.com/mailman/listinfo/xfs

# xfs_repair -v -L /dev/sde1
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

bad magic number
bad magic number
bad magic number
bad magic number
bad magic number

bad magic number
Metadata corruption detected at block 0x8/0x1000bad magic number
bad magic number

bad magic number
bad magic number
bad magic number
bad magic number
Metadata corruption detected at block 0x369497c8/0x1000
Metadata corruption detected at block 0x82fe3908/0x1000
Metadata corruption detected at block 0x20bf8e48/0x1000
Metadata corruption detected at block 0x417f1c88/0x1000
Metadata corruption detected at block 0x7813b448/0x1000
Metadata corruption detected at block 0x57542608/0x1000
Metadata corruption detected at block 0x4c69a148/0x1000
Metadata corruption detected at block 0x2baa1308/0x1000
Metadata corruption detected at block 0x6d292f88/0x1000
flasche magische # 0xfc4e2ba9 für agf 0
Metadata corruption detected at block 0x15d50988/0x1000
falsche Version # 16777216 für agf 0
falsche Länge 0 für agf 0, könnte 22892696 sein
flfirst 1631203328 in agf 0 too large (max = 1024)
falscher agf für ag 0 wird zurückgesetzt
falscher agbno 1681871612 für btbno-Wurzel, agno 0
falscher agbno 1222767762 für btbcnt-Wurzel, agno 0
Metadata corruption detected at block 0xaea84c8/0x1000
Metadata corruption detected at block 0x623eaac8/0x1000
Metadata corruption detected at block 0x8de8bdc8/0x1000
Metadata corruption detected at block 0xa3bdc748/0x1000
Metadata corruption detected at block 0x98d34288/0x1000
Metadata corruption detected at block 0x369497d0/0x1000
Metadata corruption detected at block 0x82fe3910/0x1000
falscher on-disk-Superblock 5 - falsche Magische Nummer
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

Dave Chinner

2014-09-13 22:09:16 UTC

Permalink

Post by Marko Weber|8000
an output of xfs_repair -v -L /dev/sde1

...

Post by Marko Weber|8000
# xfs_repair -v -L /dev/sde1

What version?

Post by Marko Weber|8000
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

....

Post by Marko Weber|8000
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
***@fromorbit.com

Marko Weber|8000

2014-09-16 21:27:45 UTC

Permalink

Post by Dave Chinner

Post by Marko Weber|8000
an output of xfs_repair -v -L /dev/sde1

...

Post by Marko Weber|8000
# xfs_repair -v -L /dev/sde1

What version?

first it was 3.1.10
later like posted 3.2.1

Post by Dave Chinner

....

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

Post by Dave Chinner
Cheers,
Dave.

Dave Chinner

2014-09-16 22:10:05 UTC

Permalink

Post by Marko Weber|8000

Post by Dave Chinner

Post by Marko Weber|8000
an output of xfs_repair -v -L /dev/sde1

...

Post by Marko Weber|8000
# xfs_repair -v -L /dev/sde1

What version?

first it was 3.1.10
later like posted 3.2.1

Post by Dave Chinner

....

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?

# gdb /path/to/build/area/repair/xfs_repair
....
(gdb) run <command line options for repair>
.....
<crashes>
(gdb) bt
<stack trace output emitted>

Paste the entire output of the gdb session. Best if you can run it
with your language settings to output english error messages, too
(LANG=C, I think).

As for running metadump: 'man xfs_metadump', compress the resultant
image and send me a link to where I can download it from.

Cheers,

Dave.

--
Dave Chinner
***@fromorbit.com

Carlos E. R.

2014-09-13 14:43:30 UTC

Permalink

Die Struktur muss bereinigt werden

...

the above lines with ls says "access not possible on serien and
dokutv, structure needs cleaning.

Just a comment. You can issue commands like this:

LANG=C ls -l /mnt/temp

and the output will be, for that time only, in English, so that we can
all read it ;-)

- --
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)