[Top] [All Lists]

Re: XFS filesystem recovery from secondary superblocks

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
Cc: xfs@xxxxxxxxxxx
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==
In-reply-to: <CABJyUzKe91==jXcqO6oV3a+ZeR83juhLUkqcmaVoaMib5LZkBQ@xxxxxxxxxxxxxx>
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.


On Sun, Nov 11, 2012 at 2:39 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Sat, Nov 10, 2012 at 11:08:23PM -0800, Aaron Goulding wrote:
> As I guessed, xfs_repair didn't work. xfs_db does now load with warnings,
> but I fear I don't know enough about that to properly use that tool. I've
> done a search for xfs_irepair but I'm finding very little from that. Where
> is that tool located? I'm understanding a full restore is very unlikely at
> this point, but if I can get anything, I'll consider this project a success
> and a learning experience. :)



current location:


You might need to hack it to recovery full files (ISTR is ignore
files larger than a certain size), but tools lke this are your best
bet now.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>