|To:||Dave Chinner <david@xxxxxxxxxxxxx>|
|Subject:||Re: XFS filesystem recovery from secondary superblocks|
|From:||Aaron Goulding <aarongldng@xxxxxxxxx>|
|Date:||Sat, 24 Nov 2012 16:20:18 -0800|
|Dkim-signature:||v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4DsOXCSTcB6R542BGiZzBGNyOX3lpAB0XjiOsDaEel8=; b=FciOT4Uk/MpuMXBs0AevvL1uMxZKgK35dnRXIeRWYW5TJOlVpJumM2PTf74v17eTWX 3rNUl7IRLR9sTu/Yf6GNrzMsrt1/RD7B4JD2uWElRTJrqmdysSCyDRcYkFZZb5XbcWRi eU14/j9qvGQMGnhmsqLM6I1P3dBqwB2UsxNTRzo5+mwT0DOOiycofITel6TKS3Z1fimP tToFm1O52A1h8XBkmA+GxRRp9PqtwwgowQwjCTHVbpv68MXRVZkyyaVnEvvP3KaBH1RB zWnsDPHZcmtD4BJDZG5V0Zm4yAhmHCzn7u2QdXlwG26p1rtvWVUqqeRdStS8TS0Pa0NM 5iDA==|
|References:||<CABJyUz+h=pZ6+2rro1PjoB1ggTAoRw+bTzc_bU7Eaec0_AUKLA@xxxxxxxxxxxxxx> <20121101225938.GS29378@dastard> <CABJyUz+VhUY=tVKpEeKXfQRoaL4s+gwNmRr4wNAnRX6zTt5xXg@xxxxxxxxxxxxxx> <CABJyUz+r7yQSswqyBng_W=fAXxTz9heb88NeiKSeFU7j4ZD=Hw@xxxxxxxxxxxxxx> <20121108210210.GP6434@dastard> <CABJyUzKy4YXVZAj=awVNfPD69eWo2mKhM7a-xWF1Vy-PD989sg@xxxxxxxxxxxxxx> <20121109104839.GE6434@dastard> <CABJyUzJVj-rpGW=i5QG=AZPvhuD-qdbujuwOdu_EdGbYGZ++Rg@xxxxxxxxxxxxxx> <CABJyUzJ7maOcj+aPkpCvBc1-P+Z-XPsft8rbsVnqgpfyVCs9xQ@xxxxxxxxxxxxxx> <20121111223944.GN24575@dastard> <CABJyUzKe91==jXcqO6oV3a+ZeR83juhLUkqcmaVoaMib5LZkBQ@xxxxxxxxxxxxxx>|
So an update! I did another search of /dev/md0 for superblock locations (find all instances of XFSB, find all instances of XAGF that occur 512 bytes after XFSB) and used those as start points to copy the data to /dev/md1. I took the block count from the superblock, (right at 1TB per AG) and copied that block of data to the array, properly aligned.|
This seems to have worked rather well! xfs_db now has much fewer errors, and can read SBs and AGFs, and xfs_repair can do something with it.
From here I did two things. I ran xfs_repair -L to purge the log, as I wasn't able to replay it (and some data loss is acceptable), and then I mounted the filesystem. This worked! Though it was now showing 22GB used, all in lost and found. Oops.
I noticed ag 0 reports a lot more free space than any of the others, so I tried copying sb 1 over sb 0 to get things to use the more intact blocks. No such luck yet, but I'm definitely getting some data. When I tried using sb 12, df shows 11T used (about right) but the file list is still very sparse.
So moving onward! Any recommendations from this point? I take it this is where I'd run xfs_irecover?
On Tue, Nov 13, 2012 at 7:26 PM, Aaron Goulding <aarongldng@xxxxxxxxx> wrote:
Hmm.. Okay new plan. Running XFSB and XAGF scans on /dev/md0 instead of /dev/md1, and I'll use that to find the alignment the superblocks are expecting, and see if I have an offset wrong somewhere when I ran the multi-part DD onto /dev/md1. Barring this, I'll resort to xfs_irecover. I think you've given me a lot of information to go on though, so thank you greatly.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: high load and xfsaild in d, Dave Chinner|
|Next by Date:||TOQUE DE RECOLHER ! ÃLTIMOS AVISOS DE JESUS E MARIA !.20123, JC.JOSE CARLOS|
|Previous by Thread:||Re: XFS filesystem recovery from secondary superblocks, Aaron Goulding|
|Next by Thread:||Re: XFS filesystem recovery from secondary superblocks, Dave Chinner|
|Indexes:||[Date] [Thread] [Top] [All Lists]|