From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.7]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o68J6GW8012332 for ; Thu, 8 Jul 2010 15:06:16 -0400 Received: from mail.bmsi.com (www.bmsi.com [24.248.44.156]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o68J64Yp015546 for ; Thu, 8 Jul 2010 15:06:05 -0400 Received: from bmsred.bmsi.com (bmsred.bmsi.com [192.168.9.50]) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id o68J64Sm018881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jul 2010 15:06:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by bmsred.bmsi.com (8.14.3/8.14.3) with ESMTP id o68J63fw010157 for ; Thu, 8 Jul 2010 15:06:03 -0400 Date: Thu, 8 Jul 2010 15:06:03 -0400 (EDT) From: "Stuart D. Gathman" In-Reply-To: Message-ID: References: <20100706161745.GB31734@us.ibm.com> MIME-Version: 1.0 Subject: Re: [linux-lvm] Rebuilding ext4 filesystem on an LV Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: LVM general discussion and development On Wed, 7 Jul 2010, Ken Bass wrote: > > The best course of action would have been 'reading what ever data > > available' from old disk to new disk. If the disk is absolutely > > thrashed, then zero'ing the new PV may be better. > > > > > I did try to read anything I could out of the old disk. I do believe there > is still some data on it that wasn't trashed. The problem is how to find it > and reconstruct it without any of the LVM or ext4 filesystem information > (as I said, I couldn't find any superblocks). Are there any utilities to do > something like that? Method 1: If you can, have *all* the drives connected, the failed drive, and the new drive. Restore LVM metadata to include the failed drive again. Now add the new drive and use pvmove to migrate data that can be read to the new drive. (I've never used pvmove for this purpose - does it handle IO errors and continue?) Method 2: With both new and failed drive connected, use dd_rescue or equivalent to copy (most/some of) the failed drive to the new drive. Remove failed drive and bring up VG. If UUID was not readable on failed drive, use pvcreate to restore it on new drive. -- Stuart D. Gathman Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.