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@xxxxxxxxxxx. > > 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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
