From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t29BLNSe018376 for ; Mon, 9 Mar 2015 07:21:23 -0400 Received: from mail.webx.cz (mail.webx.cz [109.123.222.201]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t29BLHBB015337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Mar 2015 07:21:18 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.webx.cz (Postfix) with ESMTP id 1F2AA3FE09 for ; Mon, 9 Mar 2015 12:21:16 +0100 (CET) Received: from mail.webx.cz ([127.0.0.1]) by localhost (mail1.webx.cz [127.0.0.1]) (amavisd-new, port 10042) with LMTP id h7Q61j-1owxf for ; Mon, 9 Mar 2015 12:21:16 +0100 (CET) Received: from libor-nb.localnet (remote.bcom.cz [88.208.120.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webx.cz (Postfix) with ESMTPSA id E3BE83FD92 for ; Mon, 9 Mar 2015 12:21:15 +0100 (CET) From: Libor =?utf-8?B?S2xlcMOhxI0=?= Date: Mon, 09 Mar 2015 12:21:15 +0100 Message-ID: <2134825.VZEVSUbKJK@libor-nb> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart6934795.QRUrDN5mdl" Content-Transfer-Encoding: 7Bit Subject: [linux-lvm] Removing disk from raid LVM 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: linux-lvm@redhat.com This is a multi-part message in MIME format. --nextPart6934795.QRUrDN5mdl Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, web have 4x3TB disks in LVM for backups and I setup per customer/per "task" LV type raid5 on it. Last week, smartd started to alarm us, that one of the disk will soon go away. So we shut down the computer, replaced disk and then i used vgcfgrestore on new disk to restore metadata. Result was, that some LVs came up with damaged filesystem, some didn't came up at all with messages like (one of rimage and rmeta was "wrong", when i used KVPM util, it was type "virtual" ---- [123995.826650] mdX: bitmap initialized from disk: read 4 pages, set 1 of 98312 bits [124071.037501] device-mapper: raid: Failed to read superblock of device at position 2 [124071.055473] device-mapper: raid: New device injected into existing array without 'rebuild' parameter specified [124071.055969] device-mapper: table: 253:83: raid: Unable to assemble array: Invalid superblocks [124071.056432] device-mapper: ioctl: error adding target to table ---- After that, i tried several combinations of lvconvert --repair and lvchange -ay --resync Without success. So i saved some data and than created new empty LV's and started backups from scratch. Today, smartd alerted on another disk. So how can i safely remove disk from VG? I tried to simulate it on VM echo 1 > /sys/block/sde/device/delete vgreduce -ff vgPecDisk2 /dev/sde #doesn't allow me to remove vgreduce --removemissing vgPecDisk2 #doesn't allow me to remove vgreduce --removemissing --force vgPecDisk2 #works, alerts me about rimage and rmeta LVS vgchange -ay vgPecDisk2 #works but LV isn't active, only rimage and rmeta LV show up. So how to safely remove soon-to-be-bad-drive and insert new drive to array? Server has no more physical space for new drive, so we cannot use pvmove. Server is debian wheezy, but kernel is 2.6.14. Lvm is in version 2.02.95-8 , but i have another copy i use for raid operations, which is in version 2.02.104 With regards Libor --nextPart6934795.QRUrDN5mdl Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Hello,

web have 4x3TB disks in LVM for backups and I setup per customer/per "task" LV type raid5 on it.

Last week, smartd started to alarm us, that one of the disk will soon go away.

So we shut down the computer, replaced disk and then i used vgcfgrestore on new disk to restore metadata.

Result was, that some LVs came up with damaged filesystem, some didn't came up at all with messages like (one of rimage and rmeta was "wrong", when i used KVPM util, it was type "virtual"

----

[123995.826650] mdX: bitmap initialized from disk: read 4 pages, set 1 of 98312 bits

[124071.037501] device-mapper: raid: Failed to read superblock of device at position 2

[124071.055473] device-mapper: raid: New device injected into existing array without 'rebuild' parameter specified

[124071.055969] device-mapper: table: 253:83: raid: Unable to assemble array: Invalid superblocks

[124071.056432] device-mapper: ioctl: error adding target to table

----

After that, i tried several combinations of

lvconvert --repair

and

lvchange -ay --resync

 

Without success. So i saved some data and than created new empty LV's and started backups from scratch.

 

Today, smartd alerted on another disk.

So how can i safely remove disk from VG?

I tried to simulate it on VM

 

echo 1 > /sys/block/sde/device/delete

vgreduce -ff vgPecDisk2 /dev/sde #doesn't allow me to remove

vgreduce --removemissing vgPecDisk2 #doesn't allow me to remove

vgreduce --removemissing --force vgPecDisk2 #works, alerts me about rimage and rmeta LVS

 

vgchange -ay vgPecDisk2 #works but LV isn't active, only rimage and rmeta LV show up.

 

So how to safely remove soon-to-be-bad-drive and insert new drive to array?

Server has no more physical space for new drive, so we cannot use pvmove.

 

Server is debian wheezy, but kernel is 2.6.14.

Lvm is in version 2.02.95-8 , but i have another copy i use for raid operations, which is in version 2.02.104

 

With regards

Libor

--nextPart6934795.QRUrDN5mdl--