From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx2.redhat.com (mx2.redhat.com [10.255.15.25]) by int-mx2.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6SDhJuM004767 for ; Fri, 28 Jul 2006 09:43:24 -0400 Received: from mail.informatik.uni-luebeck.de (cs3.informatik.uni-luebeck.de [141.83.143.73]) by mx2.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6SDhDCF006199 for ; Fri, 28 Jul 2006 09:43:14 -0400 Received: from [85.233.16.175] (ip-175-16.travedsl.de [85.233.16.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.informatik.uni-luebeck.de (Postfix) with ESMTP id 0B1AA20150 for ; Fri, 28 Jul 2006 15:43:06 +0200 (CEST) Message-ID: <44CA1479.8080909@forouher.de> Date: Fri, 28 Jul 2006 15:43:21 +0200 From: Dariush Forouher MIME-Version: 1.0 Subject: Re: [linux-lvm] Strange pvmove problem References: <44C9E4BD.9070204@forouher.de> <44CA0D67.5000008@conterra.de> In-Reply-To: <44CA0D67.5000008@conterra.de> Content-Transfer-Encoding: quoted-printable 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="iso-8859-1" To: LVM general discussion and development Dieter St=EF=BF=BDken wrote: > Dariush Forouher wrote: >> I'm trying to move PEs away from two PVs (because I want to remove the >> disks from the system), but pvmove always fails: >=20 > I had some problems with pvmove some time ago, if the PV to empty > contained parts from several different LVs. But this was due to some=20 > old bug with a 2.6.12 or 13 kernel. May be it's interesting to have > a look into /etc/lvm/backup/LVM and the associated backups, > to understand whats going on. Uhm, this is the file created right before I started pvmove: # Generated by LVM2: Fri Jul 28 10:15:24 2006 contents =3D "Text Format Volume Group" version =3D 1 description =3D "Created *before* executing 'pvmove -v /dev/hdd1 /dev/hda3'" creation_host =3D "palomar" # Linux palomar 2.6.16.16 #2 PREEMPT Sun May 14 13:56:04 CEST 2006 i686 creation_time =3D 1154074524 # Fri Jul 28 10:15:24 2006 LVM { id =3D "GoVzA8-HPSg-FNhr-6fM3-Fo94-k2IG-462F9E" seqno =3D 39 status =3D ["RESIZEABLE", "READ", "WRITE"] extent_size =3D 8192 # 4 Megabytes max_lv =3D 0 max_pv =3D 0 physical_volumes { pv0 { id =3D "uc4kn4-xMQ7-M4vw-1thl-OcCF-LIV9-aeRTn0" device =3D "/dev/hda3" # Hint only status =3D ["ALLOCATABLE"] pe_start =3D 384 pe_count =3D 33147 # 129.48 Gigabytes } pv1 { id =3D "tNzm5d-ClTt-0vJ6-ZQA9-0eYQ-IwKy-tbxV6o" device =3D "/dev/hdd1" # Hint only status =3D ["ALLOCATABLE"] pe_start =3D 384 pe_count =3D 9541 # 37.2695 Gigabytes } pv2 { id =3D "CfA2kz-5Gt8-Zshc-3Eou-fscj-1Lfn-xOEQSY" device =3D "/dev/sda3" # Hint only status =3D ["ALLOCATABLE"] pe_start =3D 384 pe_count =3D 54833 # 214.191 Gigabytes } pv3 { id =3D "L6S26w-zr8S-t0RN-si42-zWEd-rJA5-Ms0JIb" device =3D "/dev/sdb1" # Hint only status =3D ["ALLOCATABLE"] pe_start =3D 384 pe_count =3D 59618 # 232.883 Gigabytes } } logical_volumes { data { id =3D "zscrIa-BwvW-rktv-3L5P-QP67-BkfG-ri3NZL" status =3D ["READ", "WRITE", "VISIBLE"] segment_count =3D 3 segment1 { start_extent =3D 0 extent_count =3D 59618 # 232.883 Gigabyt= es type =3D "striped" stripe_count =3D 1 # linear stripes =3D [ "pv3", 0 ] } segment2 { start_extent =3D 59618 extent_count =3D 3468 # 13.5469 Gigabyt= es type =3D "striped" stripe_count =3D 1 # linear stripes =3D [ "pv1", 6073 ] } segment3 { start_extent =3D 63086 extent_count =3D 99 # 396 Megabytes type =3D "striped" stripe_count =3D 1 # linear stripes =3D [ "pv2", 54734 ] } } } } I diff'ed it againt more recent backups and against /etc/lvm/backup/LVM. They are pretty much the same (except the "seqno" attribute). I'd be already happy if I could free /dev/sda3 (which is _nearly_ unused). Then I could create a new VG and move the files around by hand (like in the old days, when we had to use partitions). But even thats not possible since all disks big enough to hold the data are bound by this (damaged?) VG. ciao Dariush