A perhaps interesting addition: xfs_metadump succeeds with
the -o option (without it it fails consistently).
If you think the dump would be useful to you I can probably
send it unobfuscated (would have to check but I don't think
there's anything sensitive in the filenames or attributes).
--
Tapani Tarvainen
On 10 Sep 12:18, Tapani Tarvainen (tapani.j.tarvainen@xxxxxx) wrote:
>
> Hi,
>
> After a rather spectacular crash we've got an xfs filesystem
> in unrepairable state: mount fails with "Structure needs cleaning",
> xfs_repair without options refuses to work (asks to mount first),
> and xfs_repair -L stopped with
>
> corrupt dinode 2151195170, extent total = 1, nblocks = 0. This is a bug.
> Please capture the filesystem metadata with xfs_metadump and
> report it to xfs@xxxxxxxxxxxx
>
> I tried to dump the metadata and it failed, too:
>
> # xfs_metadump /dev/sdata1/data1 /data2/tmp/data1_metadump
> xfs_metadump: cannot init perag data (117)
> *** glibc detected *** xfs_db: double free or corruption (!prev):
> 0x0000000003361000 ***
> ======= Backtrace: =========
> [...]
> Aborted
>
>
> At this point I'm going to give up trying to recover the data
> (recreate filesystem and restore from backup), but if you want to
> analyze it to find the bug, I have enough spare disk space to keep a
> copy for a while (took lvm snapshot of it before recovery attempt,
> could dd it to another location).
>
> The machine is running Debian Wheezy (7.8),
> kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux,
> xfsprogs version 3.1.7+b1.
> And the filesystem is 6TB in size.
>
> If you want to take a look, please let me know what I can do to help.
>
> Thank you,
>
> --
> Tapani Tarvainen
|