On Tue, Sep 16, 2014 at 11:27:45PM +0200, Marko Weber|8000 wrote: > > > 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? # 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 david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
