From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZNdSyV98H1dBIRC5pLar" Message-Id: <1057961544.9804.31.camel@hugo> Mime-Version: 1.0 Subject: [linux-lvm] pvmove Sender: linux-lvm-admin@sistina.com Errors-To: linux-lvm-admin@sistina.com Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: Date: Sat Jul 12 07:44:01 2003 List-Id: To: linux-lvm@sistina.com --=-ZNdSyV98H1dBIRC5pLar Content-Type: multipart/alternative; boundary="=-EgCdn84+nzd+4xSdeWCI" --=-EgCdn84+nzd+4xSdeWCI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What's more secure, the Redhat patched pvmove or the original one? BTW, I have a little patch to fix RedHat patched pvmove and make it work with unpatched kernels... --- lib/pv_move.c 2003-07-11 19:10:26.000000000 -0300 +++ lib/pv_move.c.rcom 2003-07-11 19:09:35.000000000 -0300 @@ -916,7 +916,7 @@ ret =3D ioctl(group, PE_LOCKED_COPY, &pe_copy_req); if (ret < 0) ret =3D -errno; - if (ret =3D=3D -EINVAL) + if (ret =3D=3D -EINVAL || ret =3D=3D -ENOTTY) ret =3D -LVM_EPV_LOCKED_COPY_EINVAL; =09 close(group); =20 Juan Pablo Gim=C3=A9nez=20 http://www.rcom.com.ar/ http://www.rcom.com.ar/comunidad/ Llave GnuPG: MIT keyserver=20 Web Rcom=20 GnuPG fingerprint: ED97 6FB8 A9BE 26A6 789B 6657 0A15 EC2B D3D8 FD2B=20 http://www.greenpeace.org.ar/secciones/cyberactivismo/nuclear.php3 --=-EgCdn84+nzd+4xSdeWCI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable What's more secure, the Redhat patched pvmove or the original one?

BTW, I have a little patch to fix RedHat patched pvmove and make it work wi= th unpatched kernels...

--- lib/pv_move.c	2003-07-11 19:10:26.000000000 -0300
+++ lib/pv_move.c.rcom	2003-07-11 19:09:35.000000000 -0300
@@ -916,7 +916,7 @@
 	ret =3D ioctl(group, PE_LOCKED_COPY, &pe_copy_req);
 	if (ret < 0)
 		ret =3D -errno;
-	if (ret =3D=3D -EINVAL)
+	if (ret =3D=3D -EINVAL || ret =3D=3D -ENOTTY)
 		ret =3D -LVM_EPV_LOCKED_COPY_EINVAL;
 =09
 	close(group);

=

Juan Pablo Giménez

http://www.rcom.com.ar/
http://www.rcom.com.ar/comuni= dad/

Llave GnuPG:
MIT keyserver
Web Rcom


GnuPG fingerprint: ED97 6FB8 A9BE 26A6 789B 6657 0A15 EC2B D3D8 FD2B

3D"http://www.greenpeac=
--=-EgCdn84+nzd+4xSdeWCI-- --=-ZNdSyV98H1dBIRC5pLar Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/DzZHmwwiUvOlMjQRAm8fAKDI9ym50Y4Xgbnoke0WoGpDOBWTnQCbB5jt fSyfB/7DctaCKooIvR4XxlQ= =7TPF -----END PGP SIGNATURE----- --=-ZNdSyV98H1dBIRC5pLar-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Thornber Subject: Re: [linux-lvm] pvmove Message-ID: <20030712132815.GA369@fib011235813.fsnet.co.uk> References: <1057961544.9804.31.camel@hugo> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1057961544.9804.31.camel@hugo> Sender: linux-lvm-admin@sistina.com Errors-To: linux-lvm-admin@sistina.com Reply-To: linux-lvm@sistina.com List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: Date: Sat Jul 12 08:29:01 2003 List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-lvm@sistina.com On Fri, Jul 11, 2003 at 07:12:26PM -0300, Juan Pablo Gim?nez wrote: > What's more secure, the Redhat patched pvmove or the original one? The origininal pvmove has some serious problems that can make it deadlock. Redhats version attempts to correct these. The most recent LVM2 tools (see Alasdairs recent email) contain a pvmove implementation as well. - Joe From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6JIEUh8005070 for ; Fri, 19 Jul 2013 14:14:30 -0400 Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6JIESKw002084 for ; Fri, 19 Jul 2013 14:14:28 -0400 Received: by mail-ee0-f51.google.com with SMTP id e52so2577956eek.10 for ; Fri, 19 Jul 2013 11:14:28 -0700 (PDT) Received: from [192.168.1.14] ([37.131.0.86]) by mx.google.com with ESMTPSA id i2sm29324260eeu.4.2013.07.19.11.14.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 11:14:27 -0700 (PDT) Message-ID: <51E981EF.3020007@gmail.com> Date: Fri, 19 Jul 2013 21:14:07 +0300 From: Martin Papik MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [linux-lvm] pvmove 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="us-ascii"; format="flowed" To: linux-lvm@redhat.com Hi everyone I'm new to the mailing list but not to LVM, until now everything was crystal clear and working fine. Now I'm either stuck or found a minor issue. I'm trying to move move extents on a physical volume. Not from one physical volume to another. root@myhost# pvmove /dev/md127:151808-152063 /dev/md127:152064-152319 No extents available for allocation root@myhost# I also tried pvmove /dev/md127:151808-152063 /dev/md127:152064 and a few other combination. There are enough free extents. The volume I've created is 1G. There's 800 GB free. I made sure the destination blocks are available, I've tried different ranges. Way below is the output of vgdisplay and a list of volumes and their extents. Is this functionality (extent shuffling) supported? I mean is this a feature, bug or ignorance on my part? PS, if you're wondering why would anyone want to move extents from a device to the very same device, you may notice in the output below that I have a few volumes spilt into pieces and I want to de-fragment it. I know it won't affect performance too much, probably at all. But it is going to help when (if?) I'm in dire need of dd if=/dev/xxx from the physical volume. Wouldn't be the first time (not the fault of LVM, disk+heat=bad blocks). Thanks in advance for any ideas or scolding :-) Martin root@myhost# vgdisplay --- Volume group --- VG Name volume System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 147 VG Access read/write VG Status resizable MAX LV 0 Cur LV 12 Open LV 9 Max PV 0 Cur PV 1 Act PV 1 VG Size 3.35 TiB PE Size 4.00 MiB Total PE 878905 Alloc PE / Size 666880 / 2.54 TiB Free PE / Size 212025 / 828.22 GiB VG UUID Gv2rC8-sMgQ-xGGK-5swv-9Gck-QA1G-k50ABy root@myhost# vgs --all -o +lv_name,lv_size,snap_percent,seg_pe_ranges,segtype,seg_size VG #PV #LV #SN Attr VSize VFree LV LSize Snap% PE Ranges Type SSize volume 1 12 0 wz--n- 3.35t 828.22g home 150.00g /dev/md127:0-25599 linear 100.00g volume 1 12 0 wz--n- 3.35t 828.22g home 150.00g /dev/md127:72085-74495 linear 9.42g volume 1 12 0 wz--n- 3.35t 828.22g home 150.00g /dev/md127:309248-319636 linear 40.58g volume 1 12 0 wz--n- 3.35t 828.22g var 20.00g /dev/md127:25600-30719 linear 20.00g volume 1 12 0 wz--n- 3.35t 828.22g usr 20.00g /dev/md127:30720-35839 linear 20.00g volume 1 12 0 wz--n- 3.35t 828.22g tmp 2.00g /dev/md127:35840-36351 linear 2.00g volume 1 12 0 wz--n- 3.35t 828.22g p2p 300.00g /dev/md127:74496-151295 linear 300.00g volume 1 12 0 wz--n- 3.35t 828.22g boot 1.00g /dev/md127:151296-151551 linear 1.00g volume 1 12 0 wz--n- 3.35t 828.22g root 4.00g /dev/md127:152320-153343 linear 4.00g volume 1 12 0 wz--n- 3.35t 828.22g copy 2.00t /dev/md127:181248-309247 linear 500.00g volume 1 12 0 wz--n- 3.35t 828.22g copy 2.00t /dev/md127:606208-712298 linear 414.42g volume 1 12 0 wz--n- 3.35t 828.22g copy 2.00t /dev/md127:156672-181247 linear 96.00g volume 1 12 0 wz--n- 3.35t 828.22g copy 2.00t /dev/md127:36352-72084 linear 139.58g volume 1 12 0 wz--n- 3.35t 828.22g copy 2.00t /dev/md127:319637-549524 linear 898.00g volume 1 12 0 wz--n- 3.35t 828.22g swap 8.00g /dev/md127:153344-155391 linear 8.00g volume 1 12 0 wz--n- 3.35t 828.22g emulate 50.00g /dev/md127:549525-562324 linear 50.00g volume 1 12 0 wz--n- 3.35t 828.22g test 1.00g /dev/md127:151552-151807 linear 1.00g volume 1 12 0 wz--n- 3.35t 828.22g test2 1.00g /dev/md127:151808-152063 linear 1.00g root@myhost# From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <51E99A85.8060901@redhat.com> Date: Fri, 19 Jul 2013 21:59:01 +0200 From: Zdenek Kabelac MIME-Version: 1.0 References: <51E981EF.3020007@gmail.com> In-Reply-To: <51E981EF.3020007@gmail.com> Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] pvmove 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="us-ascii"; format="flowed" To: LVM general discussion and development Cc: Martin Papik Dne 19.7.2013 20:14, Martin Papik napsal(a): > Hi everyone > > I'm new to the mailing list but not to LVM, until now everything was crystal > clear and working fine. Now I'm either stuck or found a minor issue. I'm > trying to move move extents on a physical volume. Not from one physical volume > to another. > > root@myhost# pvmove /dev/md127:151808-152063 /dev/md127:152064-152319 > No extents available for allocation > root@myhost# Add --alloc anywhere But I assume the tool could be a bit more smarter here. It looks more or less like a bug to me. Zdenek From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <51E9BD58.4030301@gmail.com> Date: Sat, 20 Jul 2013 01:27:36 +0300 From: Martin Papik MIME-Version: 1.0 References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> In-Reply-To: <51E99A85.8060901@redhat.com> Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] pvmove 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="us-ascii"; format="flowed" To: Zdenek Kabelac Cc: LVM general discussion and development Dear Zdenek Thank you very much, it works. I noticed a few more things. Not errors, just minor things that might be documented better or handled differently. Depending on the design philosophy. "pvmove /dev/md127:152064-152319 /dev/md127:800000 --alloc anywhere" fails because /dev/md127:xx seems to be interpreted as "one extent starting at xx", I'm not sure that's what I'd guess from the man page. "pvmove /dev/md127:152064-152319 /dev/md127:800000- --alloc anywhere" works, but the manual page indicates that the syntax is DestinationPhysicalVolume[:PE[-PE]...], which I would interpret as /dev/xx:111 OR /dev/xx:111-222, but not /dev/xx:111-, that would IMHO be DestinationPhysicalVolume[:PE[-[PE]]...]. I'd interpret /dev/md126:100 as a start of an area, since it has no explicit bound, where as /dev/md127:100-100 I would expect for a single extent, since there is an explicit bound. Does that make sense? PS, how about a syntax variant where it can be /dev/md127:100+30 meaning 30 extents starting at 100? I understand it's often better to print ranges, but maybe in some cases start+length might work better. Or start-end+length for printing, and start[-end][+length] as input, and exit with error if both end and length are specified and they don't match (start+length!=length). I'm not complaining, just suggesting enhancements. :-) Again, thank you very much for your quick and helpful response. Martin On 07/19/2013 10:59 PM, Zdenek Kabelac wrote: > Dne 19.7.2013 20:14, Martin Papik napsal(a): >> Hi everyone >> >> I'm new to the mailing list but not to LVM, until now everything was >> crystal >> clear and working fine. Now I'm either stuck or found a minor issue. I'm >> trying to move move extents on a physical volume. Not from one >> physical volume >> to another. >> >> root@myhost# pvmove /dev/md127:151808-152063 /dev/md127:152064-152319 >> No extents available for allocation >> root@myhost# > > Add --alloc anywhere > > But I assume the tool could be a bit more smarter here. > It looks more or less like a bug to me. > > Zdenek > From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 20 Jul 2013 00:20:53 +0100 From: Alasdair G Kergon Message-ID: <20130719232052.GB23574@agk-dp.fab.redhat.com> References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51E9BD58.4030301@gmail.com> Subject: Re: [linux-lvm] pvmove 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="us-ascii" Content-Transfer-Encoding: 7bit To: Martin Papik Cc: LVM general discussion and development It uses lists of ranges separated by colons. :x-y If x is missing, 0 is inserted; if y is missing, the last extent on the device is inserted. Man pages can always be improved with more examples! For +length, try the patch below. Alasdair --- a/tools/toollib.c +++ b/tools/toollib.c @@ -1001,7 +1001,7 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, const char *pvname, uint32_t size) { char *endptr; - uint32_t start, end; + uint32_t start, end, len; /* Default to whole PV */ if (!c) { @@ -1041,7 +1041,16 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, goto error; c = endptr; } + } else if (*c == '+') { /* Length? */ + c++; + if (isdigit(*c)) { + if (!xstrtouint32(c, &endptr, 10, &len)) + goto error; + c = endptr; + end = start + (len ? (len - 1) : 0); + } } + if (*c && *c != ':') goto error; From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6N2krwg009020 for ; Mon, 22 Jul 2013 22:46:53 -0400 Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6N2knjH017315 for ; Mon, 22 Jul 2013 22:46:50 -0400 Received: by mail-ea0-f171.google.com with SMTP id m14so4179311eaj.2 for ; Mon, 22 Jul 2013 19:46:49 -0700 (PDT) Received: from [192.168.1.14] ([37.131.0.205]) by mx.google.com with ESMTPSA id b7sm55199810eef.16.2013.07.22.19.46.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 19:46:48 -0700 (PDT) Message-ID: <51EDEE5E.4010009@gmail.com> Date: Tue, 23 Jul 2013 05:45:50 +0300 From: Martin Papik MIME-Version: 1.0 References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> <20130719232052.GB23574@agk-dp.fab.redhat.com> In-Reply-To: <20130719232052.GB23574@agk-dp.fab.redhat.com> Content-Type: multipart/alternative; boundary="------------000702020004070503000908" Subject: Re: [linux-lvm] pvmove 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 This is a multi-part message in MIME format. --------------000702020004070503000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank you. Is that patch going to be added to the main source code base? I think I found an error (segfault), see below. ==> I have a few more improvement suggestions. * IMHO vgs/lvs should include a column called seg_size_pe, similar to seg_start and seg_start_pe * IMHO vgs/lvs/pvs should have an command line parameter, or option modifier allowing to not display empty columns, i.e. the following command might skip displaying origin, snap%, move, log, copy%, convert, because they have no values. That would allow me to show copy_percent column only when copy is in progress. Would be nice. lvs --all -o +vg_extent_size LV VG Attr LSize Origin Snap% Move Log Copy% Convert Ext boot volume -wi-ao 1.00g 4.00m copy volume -wi-ao 2.00t 4.00m emulate volume -wi-ao 50.00g 4.00m home volume -wi-ao 150.00g 4.00m p2p volume -wi-a- 300.00g 4.00m root volume -wi-ao 4.00g 4.00m swap volume -wi-ao 8.00g 4.00m tmp volume -wi-ao 2.00g 4.00m usr volume -wi-ao 20.00g 4.00m var volume -wi-ao 20.00g 4.00m Possible error: root@localhost# lvs --rows --align Does not align, should it? *==> SEGFAULT INFO* root@localhost# pvs --all -o +vg_fmt Segmentation fault (core dumped) However the following seems to work..... root@localhost# pvs --all -o +vg_name PV VG Fmt Attr PSize PFree VG /dev/dm-0 -- 0 0 --- some entries removed for brevity ---- /dev/md127 volume lvm2 a- 5.46t 2.77t volume --- some entries removed for brevity ---- /dev/sde1 -- 0 0 Additional information that might help. root@localhost# pvs --version LVM version: 2.02.66(2) (2010-05-20) Library version: 1.02.48 (2010-05-20) Driver version: 4.22.0 root@localhost# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS" root@localhost#valgrind pvs --all -o +vg_fmt ==14584== Memcheck, a memory error detector ==14584== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==14584== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==14584== Command: pvs --all -o +vg_fmt ==14584== ==14584== Invalid read of size 8 ==14584== at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1) ==14584== by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1) ==14584== by 0x46B138: report_object (in /sbin/lvm) ==14584== by 0x423618: ??? (in /sbin/lvm) ==14584== by 0x4254B2: process_each_pv (in /sbin/lvm) ==14584== by 0x4230D3: ??? (in /sbin/lvm) ==14584== by 0x41AE60: lvm_run_command (in /sbin/lvm) ==14584== by 0x41B307: lvm2_main (in /sbin/lvm) ==14584== by 0x58CE76C: (below main) (libc-start.c:226) ==14584== Address 0x28 is not stack'd, malloc'd or (recently) free'd ==14584== ==14584== ==14584== Process terminating with default action of signal 11 (SIGSEGV) ==14584== Access not within mapped region at address 0x28 ==14584== at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1) ==14584== by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1) ==14584== by 0x46B138: report_object (in /sbin/lvm) ==14584== by 0x423618: ??? (in /sbin/lvm) ==14584== by 0x4254B2: process_each_pv (in /sbin/lvm) ==14584== by 0x4230D3: ??? (in /sbin/lvm) ==14584== by 0x41AE60: lvm_run_command (in /sbin/lvm) ==14584== by 0x41B307: lvm2_main (in /sbin/lvm) ==14584== by 0x58CE76C: (below main) (libc-start.c:226) ==14584== If you believe this happened as a result of a stack ==14584== overflow in your program's main thread (unlikely but ==14584== possible), you can try to increase the size of the ==14584== main thread stack using the --main-stacksize= flag. ==14584== The main thread stack size used in this run was 8388608. ==14584== root@localhost# ltrace pvs --all -o +vg_fmt 2>&1 | tail __ctype_toupper_loc() = 0x7f2f0e83f768 __ctype_toupper_loc() = 0x7f2f0e83f768 __ctype_toupper_loc() = 0x7f2f0e83f768 __sprintf_chk(0x1e86e88, 1, -1, 0x48daa5, 0x48dab8) = 2 dm_pool_strdup(0x1e88120, 0x1e86e88, 0x1e86e8a, 0, 0x48daa8) = 0x1e8e538 dm_pool_alloc(0x1e88120, 8, 2, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540 dm_report_field_set_value(0x1e8e508, 0x1e8e538, 0x1e8e540, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540 dm_report_field_string(0x1e88080, 0x1e8e550, 40, 0x6b1fe0, 0x1e6cfe0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ root@localhost# root@localhost# gdb --args pvs --all -o +vg_fmt GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /sbin/pvs...(no debugging symbols found)...done. (gdb) run Starting program: /sbin/pvs --all -o +vg_fmt [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". File descriptor 3 (socket:[46992174]) leaked on pvs invocation. Parent PID 14623: gdb File descriptor 4 (socket:[46992175]) leaked on pvs invocation. Parent PID 14623: gdb File descriptor 5 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb File descriptor 6 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb Program received signal SIGSEGV, Segmentation fault. 0x00007ffff757dd77 in dm_report_field_string () from /lib/libdevmapper.so.1.02.1 (gdb) disassemble dm_report_field_string Dump of assembler code for function dm_report_field_string: 0x00007ffff757dd70 <+0>: push %rbx 0x00007ffff757dd71 <+1>: mov %rsi,%rbx 0x00007ffff757dd74 <+4>: mov (%rdi),%rdi => 0x00007ffff757dd77 <+7>: mov (%rdx),%rsi 0x00007ffff757dd7a <+10>: callq 0x7ffff7570a30 0x00007ffff757dd7f <+15>: test %rax,%rax (gdb) info registers rax 0x6dd550 7198032 rbx 0x6dd550 7198032 rcx 0x6b1fe0 7020512 rdx 0x28 40 rsi 0x6dd550 7198032 rdi 0x6d7120 7172384 rbp 0x6d7080 0x6d7080 On 07/20/2013 02:20 AM, Alasdair G Kergon wrote: > It uses lists of ranges separated by colons. > > :x-y > > If x is missing, 0 is inserted; if y is missing, the last extent on the device > is inserted. > > Man pages can always be improved with more examples! > > For +length, try the patch below. > > Alasdair > > > --- a/tools/toollib.c > +++ b/tools/toollib.c > @@ -1001,7 +1001,7 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, > const char *pvname, uint32_t size) > { > char *endptr; > - uint32_t start, end; > + uint32_t start, end, len; > > /* Default to whole PV */ > if (!c) { > @@ -1041,7 +1041,16 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, > goto error; > c = endptr; > } > + } else if (*c == '+') { /* Length? */ > + c++; > + if (isdigit(*c)) { > + if (!xstrtouint32(c, &endptr, 10, &len)) > + goto error; > + c = endptr; > + end = start + (len ? (len - 1) : 0); > + } > } > + > if (*c && *c != ':') > goto error; > --------------000702020004070503000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Thank you. Is that patch going to be added to the main source code base?

I think I found an error (segfault), see below.

==> I have a few more improvement suggestions.

* IMHO vgs/lvs should include a column called seg_size_pe, similar to seg_start and seg_start_pe
* IMHO vgs/lvs/pvs should have an command line parameter, or option modifier allowing to not display empty columns, i.e. the following command might skip displaying origin, snap%, move, log, copy%, convert, because they have no values. That would allow me to show copy_percent column only when copy is in progress. Would be nice.

lvs --all -o +vg_extent_size
  LV      VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert Ext 
  boot    volume -wi-ao   1.00g                                       4.00m
  copy    volume -wi-ao   2.00t                                       4.00m
  emulate volume -wi-ao  50.00g                                       4.00m
  home    volume -wi-ao 150.00g                                       4.00m
  p2p     volume -wi-a- 300.00g                                       4.00m
  root    volume -wi-ao   4.00g                                       4.00m
  swap    volume -wi-ao   8.00g                                       4.00m
  tmp     volume -wi-ao   2.00g                                       4.00m
  usr     volume -wi-ao  20.00g                                       4.00m
  var     volume -wi-ao  20.00g                                       4.00m

Possible error:

root@localhost# lvs --rows --align
Does not align, should it?

==> SEGFAULT INFO

root@localhost# pvs --all -o +vg_fmt
Segmentation fault (core dumped)

However the following seems to work.....

root@localhost# pvs --all -o +vg_name

  PV         VG     Fmt  Attr PSize PFree VG   
  /dev/dm-0              --      0     0       
  --- some entries removed for brevity ----
  /dev/md127 volume lvm2 a-   5.46t 2.77t volume
  --- some entries removed for brevity ----
  /dev/sde1              --      0     0       

Additional information that might help.

root@localhost# pvs --version
  LVM version:     2.02.66(2) (2010-05-20)
  Library version: 1.02.48 (2010-05-20)
  Driver version:  4.22.0
root@localhost# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"

root@localhost# valgrind pvs --all -o +vg_fmt
==14584== Memcheck, a memory error detector
==14584== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==14584== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==14584== Command: pvs --all -o +vg_fmt
==14584==
==14584== Invalid read of size 8
==14584==    at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x46B138: report_object (in /sbin/lvm)
==14584==    by 0x423618: ??? (in /sbin/lvm)
==14584==    by 0x4254B2: process_each_pv (in /sbin/lvm)
==14584==    by 0x4230D3: ??? (in /sbin/lvm)
==14584==    by 0x41AE60: lvm_run_command (in /sbin/lvm)
==14584==    by 0x41B307: lvm2_main (in /sbin/lvm)
==14584==    by 0x58CE76C: (below main) (libc-start.c:226)
==14584==  Address 0x28 is not stack'd, malloc'd or (recently) free'd
==14584==
==14584==
==14584== Process terminating with default action of signal 11 (SIGSEGV)
==14584==  Access not within mapped region at address 0x28
==14584==    at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x46B138: report_object (in /sbin/lvm)
==14584==    by 0x423618: ??? (in /sbin/lvm)
==14584==    by 0x4254B2: process_each_pv (in /sbin/lvm)
==14584==    by 0x4230D3: ??? (in /sbin/lvm)
==14584==    by 0x41AE60: lvm_run_command (in /sbin/lvm)
==14584==    by 0x41B307: lvm2_main (in /sbin/lvm)
==14584==    by 0x58CE76C: (below main) (libc-start.c:226)
==14584==  If you believe this happened as a result of a stack
==14584==  overflow in your program's main thread (unlikely but
==14584==  possible), you can try to increase the size of the
==14584==  main thread stack using the --main-stacksize= flag.
==14584==  The main thread stack size used in this run was 8388608.
==14584==

root@localhost# ltrace pvs --all -o +vg_fmt 2>&1 | tail
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__sprintf_chk(0x1e86e88, 1, -1, 0x48daa5, 0x48dab8) = 2
dm_pool_strdup(0x1e88120, 0x1e86e88, 0x1e86e8a, 0, 0x48daa8) = 0x1e8e538
dm_pool_alloc(0x1e88120, 8, 2, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540
dm_report_field_set_value(0x1e8e508, 0x1e8e538, 0x1e8e540, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540
dm_report_field_string(0x1e88080, 0x1e8e550, 40, 0x6b1fe0, 0x1e6cfe0 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
root@localhost#

root@localhost# gdb --args pvs --all -o +vg_fmt
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /sbin/pvs...(no debugging symbols found)...done.
(gdb) run
Starting program: /sbin/pvs --all -o +vg_fmt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
File descriptor 3 (socket:[46992174]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 4 (socket:[46992175]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 5 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 6 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff757dd77 in dm_report_field_string () from /lib/libdevmapper.so.1.02.1
(gdb) disassemble dm_report_field_string
Dump of assembler code for function dm_report_field_string:
   0x00007ffff757dd70 <+0>:    push   %rbx
   0x00007ffff757dd71 <+1>:    mov    %rsi,%rbx
   0x00007ffff757dd74 <+4>:    mov    (%rdi),%rdi
=> 0x00007ffff757dd77 <+7>:    mov    (%rdx),%rsi
   0x00007ffff757dd7a <+10>:    callq  0x7ffff7570a30 <dm_pool_strdup@plt>
   0x00007ffff757dd7f <+15>:    test   %rax,%rax
(gdb) info registers
rax            0x6dd550    7198032
rbx            0x6dd550    7198032
rcx            0x6b1fe0    7020512
rdx            0x28    40
rsi            0x6dd550    7198032
rdi            0x6d7120    7172384
rbp            0x6d7080    0x6d7080



On 07/20/2013 02:20 AM, Alasdair G Kergon wrote:
It uses lists of ranges separated by colons.

  :x-y

If x is missing, 0 is inserted; if y is missing, the last extent on the device
is inserted.

Man pages can always be improved with more examples!

For +length, try the patch below.

Alasdair


--- a/tools/toollib.c
+++ b/tools/toollib.c
@@ -1001,7 +1001,7 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges,
 		      const char *pvname, uint32_t size)
 {
 	char *endptr;
-	uint32_t start, end;
+	uint32_t start, end, len;
 
 	/* Default to whole PV */
 	if (!c) {
@@ -1041,7 +1041,16 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges,
 					goto error;
 				c = endptr;
 			}
+		} else if (*c == '+') {	/* Length? */
+			c++;
+			if (isdigit(*c)) {
+				if (!xstrtouint32(c, &endptr, 10, &len))
+					goto error;
+				c = endptr;
+				end = start + (len ? (len - 1) : 0);
+			}
 		}
+
 		if (*c && *c != ':')
 			goto error;
 

--------------000702020004070503000908-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6O3XXWg026996 for ; Tue, 23 Jul 2013 23:33:33 -0400 Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6O3XUNE021416 for ; Tue, 23 Jul 2013 23:33:30 -0400 Received: by mail-ee0-f43.google.com with SMTP id l10so4953876eei.2 for ; Tue, 23 Jul 2013 20:33:29 -0700 (PDT) Received: from [192.168.1.14] ([37.131.0.180]) by mx.google.com with ESMTPSA id w43sm62896424eez.6.2013.07.23.20.33.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 20:33:28 -0700 (PDT) Message-ID: <51EF4AFC.2030601@gmail.com> Date: Wed, 24 Jul 2013 06:33:16 +0300 From: Martin Papik MIME-Version: 1.0 References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> <20130719232052.GB23574@agk-dp.fab.redhat.com> <51EDEE5E.4010009@gmail.com> In-Reply-To: <51EDEE5E.4010009@gmail.com> Content-Type: multipart/alternative; boundary="------------040700060906040702030303" Subject: Re: [linux-lvm] pvmove ==> segfault: pvs --all -o +vg_fmt 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 This is a multi-part message in MIME format. --------------040700060906040702030303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit No reply yet so I thought I'd modify the subject to catch someone's eye. Martin On 07/23/2013 05:45 AM, Martin Papik wrote: > > Thank you. Is that patch going to be added to the main source code base? > > I think I found an error (segfault), see below. > > ==> I have a few more improvement suggestions. > > * IMHO vgs/lvs should include a column called seg_size_pe, similar to > seg_start and seg_start_pe > * IMHO vgs/lvs/pvs should have an command line parameter, or option > modifier allowing to not display empty columns, i.e. the following > command might skip displaying origin, snap%, move, log, copy%, > convert, because they have no values. That would allow me to show > copy_percent column only when copy is in progress. Would be nice. > > lvs --all -o +vg_extent_size > LV VG Attr LSize Origin Snap% Move Log Copy% Convert Ext > boot volume -wi-ao 1.00g 4.00m > copy volume -wi-ao 2.00t 4.00m > emulate volume -wi-ao 50.00g 4.00m > home volume -wi-ao 150.00g > 4.00m > p2p volume -wi-a- 300.00g > 4.00m > root volume -wi-ao 4.00g 4.00m > swap volume -wi-ao 8.00g 4.00m > tmp volume -wi-ao 2.00g 4.00m > usr volume -wi-ao 20.00g 4.00m > var volume -wi-ao 20.00g 4.00m > > Possible error: > > root@localhost# lvs --rows --align > Does not align, should it? > > *==> SEGFAULT INFO* > > root@localhost# pvs --all -o +vg_fmt > Segmentation fault (core dumped) > > However the following seems to work..... > > root@localhost# pvs --all -o +vg_name > PV VG Fmt Attr PSize PFree VG > /dev/dm-0 -- 0 0 > --- some entries removed for brevity ---- > /dev/md127 volume lvm2 a- 5.46t 2.77t volume > --- some entries removed for brevity ---- > /dev/sde1 -- 0 0 > > Additional information that might help. > > root@localhost# pvs --version > LVM version: 2.02.66(2) (2010-05-20) > Library version: 1.02.48 (2010-05-20) > Driver version: 4.22.0 > root@localhost# cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=12.04 > DISTRIB_CODENAME=precise > DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS" > > root@localhost#valgrind pvs --all -o +vg_fmt > ==14584== Memcheck, a memory error detector > ==14584== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==14584== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright > info > ==14584== Command: pvs --all -o +vg_fmt > ==14584== > ==14584== Invalid read of size 8 > ==14584== at 0x548ED77: dm_report_field_string (in > /lib/libdevmapper.so.1.02.1) > ==14584== by 0x549006F: dm_report_object (in > /lib/libdevmapper.so.1.02.1) > ==14584== by 0x46B138: report_object (in /sbin/lvm) > ==14584== by 0x423618: ??? (in /sbin/lvm) > ==14584== by 0x4254B2: process_each_pv (in /sbin/lvm) > ==14584== by 0x4230D3: ??? (in /sbin/lvm) > ==14584== by 0x41AE60: lvm_run_command (in /sbin/lvm) > ==14584== by 0x41B307: lvm2_main (in /sbin/lvm) > ==14584== by 0x58CE76C: (below main) (libc-start.c:226) > ==14584== Address 0x28 is not stack'd, malloc'd or (recently) free'd > ==14584== > ==14584== > ==14584== Process terminating with default action of signal 11 (SIGSEGV) > ==14584== Access not within mapped region at address 0x28 > ==14584== at 0x548ED77: dm_report_field_string (in > /lib/libdevmapper.so.1.02.1) > ==14584== by 0x549006F: dm_report_object (in > /lib/libdevmapper.so.1.02.1) > ==14584== by 0x46B138: report_object (in /sbin/lvm) > ==14584== by 0x423618: ??? (in /sbin/lvm) > ==14584== by 0x4254B2: process_each_pv (in /sbin/lvm) > ==14584== by 0x4230D3: ??? (in /sbin/lvm) > ==14584== by 0x41AE60: lvm_run_command (in /sbin/lvm) > ==14584== by 0x41B307: lvm2_main (in /sbin/lvm) > ==14584== by 0x58CE76C: (below main) (libc-start.c:226) > ==14584== If you believe this happened as a result of a stack > ==14584== overflow in your program's main thread (unlikely but > ==14584== possible), you can try to increase the size of the > ==14584== main thread stack using the --main-stacksize= flag. > ==14584== The main thread stack size used in this run was 8388608. > ==14584== > > root@localhost# ltrace pvs --all -o +vg_fmt 2>&1 | tail > __ctype_toupper_loc() = 0x7f2f0e83f768 > __ctype_toupper_loc() = 0x7f2f0e83f768 > __ctype_toupper_loc() = 0x7f2f0e83f768 > __sprintf_chk(0x1e86e88, 1, -1, 0x48daa5, 0x48dab8) = 2 > dm_pool_strdup(0x1e88120, 0x1e86e88, 0x1e86e8a, 0, 0x48daa8) = 0x1e8e538 > dm_pool_alloc(0x1e88120, 8, 2, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540 > dm_report_field_set_value(0x1e8e508, 0x1e8e538, 0x1e8e540, > 0x7f2f0d892030, 0x48daa8) = 0x1e8e540 > dm_report_field_string(0x1e88080, 0x1e8e550, 40, 0x6b1fe0, 0x1e6cfe0 > > --- SIGSEGV (Segmentation fault) --- > +++ killed by SIGSEGV +++ > root@localhost# > > root@localhost# gdb --args pvs --all -o +vg_fmt > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /sbin/pvs...(no debugging symbols found)...done. > (gdb) run > Starting program: /sbin/pvs --all -o +vg_fmt > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > File descriptor 3 (socket:[46992174]) leaked on pvs invocation. Parent > PID 14623: gdb > File descriptor 4 (socket:[46992175]) leaked on pvs invocation. Parent > PID 14623: gdb > File descriptor 5 (pipe:[46992176]) leaked on pvs invocation. Parent > PID 14623: gdb > File descriptor 6 (pipe:[46992176]) leaked on pvs invocation. Parent > PID 14623: gdb > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff757dd77 in dm_report_field_string () from > /lib/libdevmapper.so.1.02.1 > (gdb) disassemble dm_report_field_string > Dump of assembler code for function dm_report_field_string: > 0x00007ffff757dd70 <+0>: push %rbx > 0x00007ffff757dd71 <+1>: mov %rsi,%rbx > 0x00007ffff757dd74 <+4>: mov (%rdi),%rdi > => 0x00007ffff757dd77 <+7>: mov (%rdx),%rsi > 0x00007ffff757dd7a <+10>: callq 0x7ffff7570a30 > 0x00007ffff757dd7f <+15>: test %rax,%rax > (gdb) info registers > rax 0x6dd550 7198032 > rbx 0x6dd550 7198032 > rcx 0x6b1fe0 7020512 > rdx 0x28 40 > rsi 0x6dd550 7198032 > rdi 0x6d7120 7172384 > rbp 0x6d7080 0x6d7080 > > > > On 07/20/2013 02:20 AM, Alasdair G Kergon wrote: >> It uses lists of ranges separated by colons. >> >> :x-y >> >> If x is missing, 0 is inserted; if y is missing, the last extent on the device >> is inserted. >> >> Man pages can always be improved with more examples! >> >> For +length, try the patch below. >> >> Alasdair >> >> >> --- a/tools/toollib.c >> +++ b/tools/toollib.c >> @@ -1001,7 +1001,7 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, >> const char *pvname, uint32_t size) >> { >> char *endptr; >> - uint32_t start, end; >> + uint32_t start, end, len; >> >> /* Default to whole PV */ >> if (!c) { >> @@ -1041,7 +1041,16 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges, >> goto error; >> c = endptr; >> } >> + } else if (*c == '+') { /* Length? */ >> + c++; >> + if (isdigit(*c)) { >> + if (!xstrtouint32(c, &endptr, 10, &len)) >> + goto error; >> + c = endptr; >> + end = start + (len ? (len - 1) : 0); >> + } >> } >> + >> if (*c && *c != ':') >> goto error; >> > --------------040700060906040702030303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

No reply yet so I thought I'd modify the subject to catch someone's eye.

Martin

On 07/23/2013 05:45 AM, Martin Papik wrote:

Thank you. Is that patch going to be added to the main source code base?

I think I found an error (segfault), see below.

==> I have a few more improvement suggestions.

* IMHO vgs/lvs should include a column called seg_size_pe, similar to seg_start and seg_start_pe
* IMHO vgs/lvs/pvs should have an command line parameter, or option modifier allowing to not display empty columns, i.e. the following command might skip displaying origin, snap%, move, log, copy%, convert, because they have no values. That would allow me to show copy_percent column only when copy is in progress. Would be nice.

lvs --all -o +vg_extent_size
  LV      VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert Ext 
  boot    volume -wi-ao   1.00g                                       4.00m
  copy    volume -wi-ao   2.00t                                       4.00m
  emulate volume -wi-ao  50.00g                                       4.00m
  home    volume -wi-ao 150.00g                                       4.00m
  p2p     volume -wi-a- 300.00g                                       4.00m
  root    volume -wi-ao   4.00g                                       4.00m
  swap    volume -wi-ao   8.00g                                       4.00m
  tmp     volume -wi-ao   2.00g                                       4.00m
  usr     volume -wi-ao  20.00g                                       4.00m
  var     volume -wi-ao  20.00g                                       4.00m

Possible error:

root@localhost# lvs --rows --align
Does not align, should it?

==> SEGFAULT INFO

root@localhost# pvs --all -o +vg_fmt
Segmentation fault (core dumped)

However the following seems to work.....

root@localhost# pvs --all -o +vg_name

  PV         VG     Fmt  Attr PSize PFree VG   
  /dev/dm-0              --      0     0       
  --- some entries removed for brevity ----
  /dev/md127 volume lvm2 a-   5.46t 2.77t volume
  --- some entries removed for brevity ----
  /dev/sde1              --      0     0       

Additional information that might help.

root@localhost# pvs --version
  LVM version:     2.02.66(2) (2010-05-20)
  Library version: 1.02.48 (2010-05-20)
  Driver version:  4.22.0
root@localhost# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"

root@localhost# valgrind pvs --all -o +vg_fmt
==14584== Memcheck, a memory error detector
==14584== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==14584== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==14584== Command: pvs --all -o +vg_fmt
==14584==
==14584== Invalid read of size 8
==14584==    at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x46B138: report_object (in /sbin/lvm)
==14584==    by 0x423618: ??? (in /sbin/lvm)
==14584==    by 0x4254B2: process_each_pv (in /sbin/lvm)
==14584==    by 0x4230D3: ??? (in /sbin/lvm)
==14584==    by 0x41AE60: lvm_run_command (in /sbin/lvm)
==14584==    by 0x41B307: lvm2_main (in /sbin/lvm)
==14584==    by 0x58CE76C: (below main) (libc-start.c:226)
==14584==  Address 0x28 is not stack'd, malloc'd or (recently) free'd
==14584==
==14584==
==14584== Process terminating with default action of signal 11 (SIGSEGV)
==14584==  Access not within mapped region at address 0x28
==14584==    at 0x548ED77: dm_report_field_string (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x549006F: dm_report_object (in /lib/libdevmapper.so.1.02.1)
==14584==    by 0x46B138: report_object (in /sbin/lvm)
==14584==    by 0x423618: ??? (in /sbin/lvm)
==14584==    by 0x4254B2: process_each_pv (in /sbin/lvm)
==14584==    by 0x4230D3: ??? (in /sbin/lvm)
==14584==    by 0x41AE60: lvm_run_command (in /sbin/lvm)
==14584==    by 0x41B307: lvm2_main (in /sbin/lvm)
==14584==    by 0x58CE76C: (below main) (libc-start.c:226)
==14584==  If you believe this happened as a result of a stack
==14584==  overflow in your program's main thread (unlikely but
==14584==  possible), you can try to increase the size of the
==14584==  main thread stack using the --main-stacksize= flag.
==14584==  The main thread stack size used in this run was 8388608.
==14584==

root@localhost# ltrace pvs --all -o +vg_fmt 2>&1 | tail
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__ctype_toupper_loc()                            = 0x7f2f0e83f768
__sprintf_chk(0x1e86e88, 1, -1, 0x48daa5, 0x48dab8) = 2
dm_pool_strdup(0x1e88120, 0x1e86e88, 0x1e86e8a, 0, 0x48daa8) = 0x1e8e538
dm_pool_alloc(0x1e88120, 8, 2, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540
dm_report_field_set_value(0x1e8e508, 0x1e8e538, 0x1e8e540, 0x7f2f0d892030, 0x48daa8) = 0x1e8e540
dm_report_field_string(0x1e88080, 0x1e8e550, 40, 0x6b1fe0, 0x1e6cfe0 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
root@localhost#

root@localhost# gdb --args pvs --all -o +vg_fmt
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /sbin/pvs...(no debugging symbols found)...done.
(gdb) run
Starting program: /sbin/pvs --all -o +vg_fmt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
File descriptor 3 (socket:[46992174]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 4 (socket:[46992175]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 5 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb
File descriptor 6 (pipe:[46992176]) leaked on pvs invocation. Parent PID 14623: gdb

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff757dd77 in dm_report_field_string () from /lib/libdevmapper.so.1.02.1
(gdb) disassemble dm_report_field_string
Dump of assembler code for function dm_report_field_string:
   0x00007ffff757dd70 <+0>:    push   %rbx
   0x00007ffff757dd71 <+1>:    mov    %rsi,%rbx
   0x00007ffff757dd74 <+4>:    mov    (%rdi),%rdi
=> 0x00007ffff757dd77 <+7>:    mov    (%rdx),%rsi
   0x00007ffff757dd7a <+10>:    callq  0x7ffff7570a30 <dm_pool_strdup@plt>
   0x00007ffff757dd7f <+15>:    test   %rax,%rax
(gdb) info registers
rax            0x6dd550    7198032
rbx            0x6dd550    7198032
rcx            0x6b1fe0    7020512
rdx            0x28    40
rsi            0x6dd550    7198032
rdi            0x6d7120    7172384
rbp            0x6d7080    0x6d7080



On 07/20/2013 02:20 AM, Alasdair G Kergon wrote:
It uses lists of ranges separated by colons.

  :x-y

If x is missing, 0 is inserted; if y is missing, the last extent on the device
is inserted.

Man pages can always be improved with more examples!

For +length, try the patch below.

Alasdair


--- a/tools/toollib.c
+++ b/tools/toollib.c
@@ -1001,7 +1001,7 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges,
 		      const char *pvname, uint32_t size)
 {
 	char *endptr;
-	uint32_t start, end;
+	uint32_t start, end, len;
 
 	/* Default to whole PV */
 	if (!c) {
@@ -1041,7 +1041,16 @@ static int _parse_pes(struct dm_pool *mem, char *c, struct dm_list *pe_ranges,
 					goto error;
 				c = endptr;
 			}
+		} else if (*c == '+') {	/* Length? */
+			c++;
+			if (isdigit(*c)) {
+				if (!xstrtouint32(c, &endptr, 10, &len))
+					goto error;
+				c = endptr;
+				end = start + (len ? (len - 1) : 0);
+			}
 		}
+
 		if (*c && *c != ':')
 			goto error;
 


--------------040700060906040702030303-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 23 Sep 2013 21:38:41 +0100 From: Alasdair G Kergon Message-ID: <20130923203841.GC24022@agk-dp.fab.redhat.com> References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> <20130719232052.GB23574@agk-dp.fab.redhat.com> <51EDEE5E.4010009@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51EDEE5E.4010009@gmail.com> Subject: Re: [linux-lvm] pvmove 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="us-ascii" Content-Transfer-Encoding: 7bit To: Martin Papik Cc: LVM general discussion and development On Tue, Jul 23, 2013 at 05:45:50AM +0300, Martin Papik wrote: > Thank you. Is that patch going to be added to the main source code base? Committed for 2.02.103. > I think I found an error (segfault), see below. > LVM version: 2.02.66(2) (2010-05-20) I've no interest in bugs reported against such an old version of the code, I'm afraid. If you reproduce with upstream code, then we'll look into it. Alasdair From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 23 Sep 2013 21:56:42 +0100 From: Alasdair G Kergon Message-ID: <20130923205642.GD24022@agk-dp.fab.redhat.com> References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> <20130719232052.GB23574@agk-dp.fab.redhat.com> <51EDEE5E.4010009@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51EDEE5E.4010009@gmail.com> Subject: Re: [linux-lvm] pvmove 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="us-ascii" Content-Transfer-Encoding: 7bit To: Martin Papik Cc: LVM general discussion and development On Tue, Jul 23, 2013 at 05:45:50AM +0300, Martin Papik wrote: > ==> I have a few more improvement suggestions. > * IMHO vgs/lvs should include a column called seg_size_pe, similar to > seg_start and seg_start_pe Implemented for 2.02.103. https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=11dc6a03c4cdd10bc4065c7d7a8585373455f947 Alasdair From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 23 Sep 2013 22:10:49 +0100 From: Alasdair G Kergon Message-ID: <20130923211049.GE24022@agk-dp.fab.redhat.com> References: <51E981EF.3020007@gmail.com> <51E99A85.8060901@redhat.com> <51E9BD58.4030301@gmail.com> <20130719232052.GB23574@agk-dp.fab.redhat.com> <51EDEE5E.4010009@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51EDEE5E.4010009@gmail.com> Subject: Re: [linux-lvm] pvmove 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="us-ascii" Content-Transfer-Encoding: 7bit To: Martin Papik Cc: LVM general discussion and development On Tue, Jul 23, 2013 at 05:45:50AM +0300, Martin Papik wrote: > * IMHO vgs/lvs/pvs should have an command line parameter, or option > modifier allowing to not display empty columns, i.e. the following > command might skip displaying origin, snap%, move, log, copy%, convert, > because they have no values. That would allow me to show copy_percent > column only when copy is in progress. Would be nice. Yes - I'm surprised we never had this suggested before. - Some columns will gain a property saying they can be suppressed when empty. - A new cmdline option/config setting to suppress empty fields. - Implemented as an extension alongside the 'sort' option. (Like sort, you have to have all the output data prepared before you find out whether any columns are empty - even the headings can't be output before this point.) - A way to flag an output data entry as empty. (zkabelac is about to commit some patches to tidy up the handling of empty fields so this change can follow those.) Alasdair