From: Marc des Garets <marc@ttux.net>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] broken fs after removing disk from group
Date: Fri, 14 Nov 2014 09:42:34 +0100 [thread overview]
Message-ID: <5465C07A.2080707@ttux.net> (raw)
In-Reply-To: <54650ED4.7030409@ttux.net>
I am even able to mount the volume actually now and get to the data but
I can't do a fsck on the disk because of the difference of block between
physical size and filesystem size. I really don't feel like copying all
my data to recreate the lvm from scratch...
I tried what was suggested here:
http://sourceforge.net/p/e2fsprogs/discussion/7053/thread/c9e05785/
debugfs -w /dev/sda1
debugfs: set_super_value blocks_count 597721088
debugfs: quit
Where I had to compile e2fsprogs as explained in the thread but it
didn't work out anyway. All I gained from doing this is another warning
when running fsck:
ext2fs_open2: The ext2 superblock is corrupt
fsck.ext4: Superblock invalid, trying backup blocks...
Guess it's happy with the backup blocks but it still complains about
difference in block size.
On 11/13/2014 09:04 PM, Marc des Garets wrote:
> Yes, it's human readable. It's the one I sent in my previous email.
>
> lvdisplay gives the following:
> --- Logical volume ---
> LV Path /dev/VolGroup00/lvolmedia
> LV Name lvolmedia
> VG Name VolGroup00
> LV UUID aidfLk-hjlx-Znrp-I0Pb-JtfS-9Fcy-OqQ3EW
> LV Write Access read/write
> LV Creation host, time archiso, 2014-06-09 10:32:20 +0200
> LV Status suspended
> # open 0
> LV Size 2.52 TiB
> Current LE 660023
> Segments 3
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:0
>
>
> On 11/13/2014 08:48 PM, matthew patton wrote:
>>> https://www.novell.com/coolsolutions/appnote/19386.html#DiskPermanentlyRemoved
>>>
>> > pvdisplay shows the 3 disks exactly like before I had the one
>> that
>>
>>> The filesystem size (according to the superblock) is 675863552 blocks
>>> The physical size of the device is 597721088 blocks
>> what about LVdisplay? Clearly the replacement chunk from the new
>> device isn't the correct size. It's short by 39071232KB or roughly 37GB.
>>
>> Is the VG configuration restore file human readable?
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
next prev parent reply other threads:[~2014-11-14 8:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 22:16 [linux-lvm] broken fs after removing disk from group Marc des Garets
2014-11-12 23:11 ` Fran Garcia
2014-11-13 7:21 ` Marc des Garets
2014-11-13 9:47 ` Marc des Garets
2014-11-13 19:27 ` Marc des Garets
2014-11-13 19:48 ` matthew patton
2014-11-13 20:04 ` Marc des Garets
2014-11-14 8:42 ` Marc des Garets [this message]
2014-11-14 17:12 ` Jack Waterworth
2014-11-14 19:16 ` Marc des Garets
2014-11-14 19:30 ` Marc des Garets
2014-11-14 20:54 ` Marc des Garets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5465C07A.2080707@ttux.net \
--to=marc@ttux.net \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.