Skip to contentSkip to conversation

unclean shutdown of usb hdd destroyed xfs partially

DISCUSSION Marko Weber|8000 3 participants 6 messages Sep 13, 2014 – Sep 16, 2014

lore
Share & tools
lore
#0 lore raw

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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw

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

Am 2014-09-13 16:33, schrieb Marko Weber|8000:

Quoted 27 lines

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?

Quoted 8 lines

thanks for any hints or help

marko

_______________________________________________
xfs mailing list
[email protected]
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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#2 lore raw
Quoted 2 lines · On Sat, Sep 13, 2014 at 04:36:59PM +0200, Marko Weber|8000 wrote:

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

...

Quoted 2 lines
 # xfs_repair -v -L /dev/sde1

What version?

Quoted 9 lines

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

....

Quoted 8 lines

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

Quoted 11 lines

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.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#3 lore raw

Am 2014-09-14 00:09, schrieb Dave Chinner:

Quoted 8 lines · On Sat, Sep 13, 2014 at 04:36:59PM +0200, Marko Weber|8000 wrote:
Quoted 2 lines

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

...

Quoted 2 lines
 # xfs_repair -v -L /dev/sde1

What version?

first it was 3.1.10
later like posted 3.2.1

Quoted 37 lines
Quoted 10 lines

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

....

Quoted 8 lines

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

Quoted 11 lines

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.

Quoted 4 lines

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

Quoted 4 lines

Cheers,

Dave.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#4 lore raw
Quoted 57 lines · On Tue, Sep 16, 2014 at 11:27:45PM +0200, Marko Weber|8000 wrote:

Am 2014-09-14 00:09, schrieb Dave Chinner:

Quoted 8 lines · On Sat, Sep 13, 2014 at 04:36:59PM +0200, Marko Weber|8000 wrote:
Quoted 2 lines

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

...

Quoted 2 lines
# xfs_repair -v -L /dev/sde1

What version?

first it was 3.1.10
later like posted 3.2.1

Quoted 37 lines
Quoted 10 lines

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

....

Quoted 8 lines

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

Quoted 11 lines

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.

Quoted 4 lines

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?

Quoted 4 lines

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.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#5 lore raw
In reply to Marko Weber|8000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 2 lines · On 2014-09-13 16:33, Marko Weber|8000 wrote:
# ls -l /mnt/temp ls: Zugriff auf /mnt/temp/serien nicht möglich:
Die Struktur muss bereinigt werden

...

Quoted 2 lines

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)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlQUWBAACgkQtTMYHG2NR9WslgCeNCsAiQA21UaQWl28qipLwOTK nnsAn09/oQlsrkDwlF2TYznumgK5sXnI
=ipKe
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs