Bug 220155 - Linux ppc64:lvm command pvmove is not getting completed when more than 4 extends are moved
Linux ppc64:lvm command pvmove is not getting completed when more than 4 exte...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.3
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Alasdair Kergon
Corey Marthaler
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-19 07:09 EST by Sudhakar Kasina
Modified: 2007-11-16 20:14 EST (History)
6 users (show)

See Also:
Fixed In Version: RHEL4.4 kernel
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-20 11:51:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Strace output of pvmove command (134.05 KB, text/plain)
2006-12-19 07:09 EST, Sudhakar Kasina
no flags Details

  None (edit)
Description Sudhakar Kasina 2006-12-19 07:09:13 EST
Description of problem:

 pvmove --alloc anywhere /dev/sdb3:0-4 /dev/sdb3:256-267
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%

The above message is displayed for infinitely and pvmove never completes.
This happens for moving 5 or more than 5 extents. 
pvmove is successful for 4 or below 4 extents movement.

Configuration
================

OS : RHEL4 UP3
Architecture : PPC64
uname -a : Linux lopgod04.vxindia.veritas.com 2.6.9-34.ELv #1 SMP Mon Sep 25
13:31:34 BST 2006 ppc64 ppc64 ppc64 GNU/Linux
Internal disk of size 73GB (sdb)  : using sdb3 for the LVM operations

I am using sdb which is not boot disk ( I have sda as boot disk in my setup)

fdisk -l /dev/sdb
 
Disk /dev/sdb: 73.4 GB, 73407488000 bytes
128 heads, 32 sectors/track, 35003 cylinders
Units = cylinders of 4096 * 512 = 2097152 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1           1         172+  41  PPC PReP Boot
Partition 1 does not end on cylinder boundary.
/dev/sdb2               7        2007     4098048   82  Linux swap
/dev/sdb3            2010        6778     9766912   83  Linux
/dev/sdb4            6800       11568     9766912    5  Extended



Version-Release number of selected component (if applicable):

lvm2-2.02.01-1.3.RHEL4
system-config-lvm-1.0.16-1.0

  LVM version:     2.01.14 (2005-08-04)
  Library version: 1.01.01 (2005-03-29)
  Driver version:  4.4.0


How reproducible:


1. Created partition on /dev/sdb named /dev/sdb3 or size 10G  between 2010 and
6778 as above

2.  pvcreate /dev/sdb3
    vgcreate  lopvg4 /dev/sdb3
    lvcreate -L 5G -n loplv4 lopvg4
   
3. lvdisplay --map
 
 --- Logical volume ---
  LV Name                /dev/lopvg4/loplv4
  VG Name                lopvg4
  LV UUID                62ZATJ-IMKa-xmOk-kmOG-f5LG-Dle8-1Ksaur
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                5.00 GB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:0
    
  --- Segments ---
  Logical extent 0 to 1279:
    Type                linear
    Physical volume     /dev/sdb3
    Physical extents    0 to 1279


 4.  Moving 5 extents using pvmove


 pvmove --alloc anywhere /dev/sdb3:0-4 /dev/sdb3:1290-1294
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%

	The above message is displayed for infinitely and pvmove never completes.
	This happens only for moving 4 or above 4 number of extents ..

5. pvmode is successful for moving 4 or less extents as below  

   pvmove --alloc anywhere /dev/sdb3:0-3 /dev/sdb3:1290-1293
  /dev/sdb3: Moved: 100.0%

  lvdisplay --map
  --- Logical volume ---
  LV Name                /dev/lopvg4/loplv4
  VG Name                lopvg4
  LV UUID                62ZATJ-IMKa-xmOk-kmOG-f5LG-Dle8-1Ksaur
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                5.00 GB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:0
    
  --- Segments ---
  Logical extent 0 to 3:
    Type                linear
    Physical volume     /dev/sdb3
    Physical extents    1290 to 1293
    
  Logical extent 4 to 1279:
    Type                linear
    Physical volume     /dev/sdb3
    Physical extents    4 to 1279

Steps to Reproduce:
  1.  pvcreate /dev/sdb3
  2.  vgcreate  lopvg4 /dev/sdb3
  3.  lvcreate -L 5G -n loplv4 lopvg4
  4.  pvmove --alloc anywhere /dev/sdb3:0-4 /dev/sdb3:1290-1294
  
Actual results:
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%
  /dev/sdb3: Moved: 80.0%

	The above message is displayed for infinitely and pvmove never completes.This
happens only for moving 4 or above 4 number of extents ..
pvmove is not exiting and continue to display above message.


Expected results:
pvmove should be successful and message should be shown as
/dev/sdb3: Moved: 100.0%


Additional info:

Attached the Strace output for pvmove command
Comment 1 Sudhakar Kasina 2006-12-19 07:09:13 EST
Created attachment 143992 [details]
Strace output of pvmove command
Comment 5 Alasdair Kergon 2006-12-20 11:37:52 EST
Please attach to the bugzilla the output of 'dmsetup status' after the hang. 
The pvmove process is waiting until it sees N/N in the output (e.g. 100/100 if
100 extents are moving.)
Comment 6 Alasdair Kergon 2006-12-20 11:40:17 EST
That this is only seen on one arch suggests it could be a manifestation of an
old bug: need to check if the kernel contains the patch or not.
Comment 7 Alasdair Kergon 2006-12-20 11:42:47 EST
Looks like this patch in the U4 kernel:  [RHEL4 U4] device-mapper mirroring: log
bitset fix BE find_next_zero_bit
Comment 8 Alasdair Kergon 2006-12-20 11:46:52 EST
or possibly this one: device-mapper mirroring: corruption with big endian 64-bit log
Comment 9 Alasdair Kergon 2006-12-20 11:51:57 EST
So please try to reproduce with a U4 kernel, and reopen this against U4 if you
still see the problem.

Note You need to log in before you can comment on or make changes to this bug.