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 o682kmHZ004887 for ; Wed, 7 Jul 2010 22:46:48 -0400 Received: from mail-pw0-f46.google.com (mail-pw0-f46.google.com [209.85.160.46]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o682kaOO032472 for ; Wed, 7 Jul 2010 22:46:36 -0400 Received: by pwi5 with SMTP id 5so145405pwi.33 for ; Wed, 07 Jul 2010 19:46:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100706161745.GB31734@us.ibm.com> References: <20100706161745.GB31734@us.ibm.com> Date: Wed, 7 Jul 2010 19:46:36 -0700 Message-ID: From: Ken Bass Content-Type: multipart/alternative; boundary=000e0cd32be8809910048ad74bc3 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: To: LVM general discussion and development --000e0cd32be8809910048ad74bc3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 6, 2010 at 9:17 AM, Malahal Naineni wrote: > If everything went right, he should have the new PV in the LV, but looks > like something failed while activating the LV. Run 'dmsetup table' to > find out if the LV currently has new PV or old PV. You need > device-mapper knowledge for this. > > I will have to try that out. Will let you know. > > 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? Then there are the remaining drives that weren't affected. Unfortunately without the first drive, I can't get to anything on the others. Or can I? I've tried several things, but I haven't found anything that works. Are there any utilities for that? I found an app that will scan a disk looking for lost partitions, and then looking for various filesystems within them - and it does recognize ext2/3. It will then recover files at that point. But it runs on windows (won't work with wine), and it is taking several days to scan the entire drive (100G). Also, there could be several hundred files, and trying to identify all of those (possibly) recovered files would be excrutiating :-( . As always, thx everyone for your help. ken --000e0cd32be8809910048ad74bc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 6, 2010 at 9:17 AM, Malahal = Naineni <malahal= @us.ibm.com> wrote:
=A0
If everything went right, he should have the new PV in the LV, but looks like something failed while activating the LV. Run 'dmsetup table' = to
find out if the LV currently has new PV or old PV. You need
device-mapper knowledge for this.

I will have to try that out. = Will let you know.
=A0

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.

=A0
I did try to read anything I could out of the old disk. I do believ= e there is still some data on it that wasn't trashed. The problem is ho= w to find it and reconstruct it without any of the LVM or ext4 filesystem= =A0 information (as I said, I couldn't find any superblocks). Are there= any utilities to do something like that?

Then there are the remaining drives that weren't affected. Unfortun= ately without the first drive, I can't get to anything on the others. O= r can I? I've tried several things, but I haven't found anything th= at works. Are there any utilities for that?

I found an app that will scan a disk looking for lost partitions, and t= hen looking for various filesystems within them - and it does recognize ext= 2/3. It will then recover files at that point. But it runs on windows (won&= #39;t work with wine), and it is taking several days to scan the entire dri= ve (100G). Also, there could be several hundred files, and trying to identi= fy all of those (possibly) recovered files would be excrutiating :-( .

As always, thx everyone for your help.

ken
--000e0cd32be8809910048ad74bc3--