* [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page @ 2007-03-26 0:11 ben scott 2007-03-26 9:05 ` Milan Broz 0 siblings, 1 reply; 8+ messages in thread From: ben scott @ 2007-03-26 0:11 UTC (permalink / raw) To: linux-lvm The explanation of the attribute bits printed by the program "vgs" in the man page are as follows: The vg_attr bits are: (w)riteable, (r)ead only, resi(z)eable, e(x)ported, (p)artial and (c)lustered. However "vgs" on my debian Etch system prints out this way: wz--n- LVM version: 2.02.07 (2006-07-17) Library version: 1.02.12 (2006-10-13) Driver version: 4.7.0 Could someone please explain to me what the "n" stands for and which columns get the other bits. I am trying to write a parser for this output. Thank you. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page 2007-03-26 0:11 [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page ben scott @ 2007-03-26 9:05 ` Milan Broz 2007-03-26 18:38 ` ben scott 2007-03-26 22:47 ` A bug in report.c? WAS: " ben scott 0 siblings, 2 replies; 8+ messages in thread From: Milan Broz @ 2007-03-26 9:05 UTC (permalink / raw) To: LVM general discussion and development ben scott wrote: > The explanation of the attribute bits printed by the program "vgs" in the man > page are as follows: > > The vg_attr bits are: (w)riteable, (r)ead only, resi(z)eable, e(x)ported, > (p)artial and (c)lustered. > > However "vgs" on my debian Etch system prints out this way: ... See lib/report/report.c in sources for exact description, Short overview (note that some attributes are used for hidden volumes only which are parts of snapshot, mirror, etc...) PV attributes a- |`- exported (vg) [x|-] `-- allocatable [a|-] VG attributes wz--n- |||||`- clustered [c|-] ||||`-- allocation policy (c)ontiguous,(C)ling,(n)ormal,(a)nywhere,(i)nherit |||`--- partial vg [p|-] ||`---- exported vg [x|-] |`----- resizeable vg [z|-] `------ writable [w|r] LV attributes -wi-a- |||||`- open [o|-] ||||`-- (s)uspended,(a)ctive,(i)nactive((d)without mapping table), |||| (I)nvalid snapshot, invalid (S)uspended snapshot [s|a|i|d|S|I] |||`--- fixed minor [m|-] ||`---- allocation policy (if locked ->capitalized) [c|C|n|a|i] |`----- writable (in pvmove '-') [w|r|-] `------ type: (p)vmoved, (m)irrored ((M) not synced), mirror (i)mage,(l)og, (v)irtual, snapshot (o)rigin/(s)cow [p|m|M|i|l|v|o|s|-] Milan -- mbroz@redhat.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page 2007-03-26 9:05 ` Milan Broz @ 2007-03-26 18:38 ` ben scott 2007-03-26 18:51 ` Alasdair G Kergon 2007-03-26 22:47 ` A bug in report.c? WAS: " ben scott 1 sibling, 1 reply; 8+ messages in thread From: ben scott @ 2007-03-26 18:38 UTC (permalink / raw) To: LVM general discussion and development On Monday 26 March 2007 02:05:41 am Milan Broz wrote: > ben scott wrote: > > The explanation of the attribute bits printed by the program "vgs" in the > > man page are as follows: > > > > The vg_attr bits are: (w)riteable, (r)ead only, resi(z)eable, > > e(x)ported, (p)artial and (c)lustered. > > > > However "vgs" on my debian Etch system prints out this way: > > ... > > See lib/report/report.c in sources for exact description, > > |||| (c)ontiguous,(C)ling,(n)ormal,(a)nywhere,(i)nherit Thank you. Now I am off to see what (C)ling means. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page 2007-03-26 18:38 ` ben scott @ 2007-03-26 18:51 ` Alasdair G Kergon 0 siblings, 0 replies; 8+ messages in thread From: Alasdair G Kergon @ 2007-03-26 18:51 UTC (permalink / raw) To: LVM general discussion and development On Mon, Mar 26, 2007 at 11:38:33AM -0700, ben scott wrote: > Thank you. Now I am off to see what (C)ling means. See 'man lvm' (if your version is new enough to support it). Alasdair -- agk@redhat.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* A bug in report.c? WAS: [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page 2007-03-26 9:05 ` Milan Broz 2007-03-26 18:38 ` ben scott @ 2007-03-26 22:47 ` ben scott 2007-03-27 1:00 ` Jun'ichi Nomura 1 sibling, 1 reply; 8+ messages in thread From: ben scott @ 2007-03-26 22:47 UTC (permalink / raw) To: LVM general discussion and development On Monday 26 March 2007 02:05:41 am Milan Broz wrote: > > See lib/report/report.c in sources for exact description, > > Short overview > (note that some attributes are used for hidden volumes only which are parts > of snapshot, mirror, etc...) > > VG attributes > > wz--n- > > |||||`- clustered [c|-] > |||| > ||||`-- allocation policy > |||| (c)ontiguous,(C)ling,(n)ormal,(a)nywhere,(i)nherit > ||| <From the LVM2.2.02.24 source> The following lines in report.c seems to show that (c) will become (C) if the lv is locked: repstr[2] = _alloc_policy_char(lv->alloc); if (lv->status & LOCKED) repstr[2] = toupper(repstr[2]); That is also what the man page claims. However the start of report.c show this: switch (alloc) { case ALLOC_CONTIGUOUS: return 'c'; case ALLOC_CLING: return 'C'; case ALLOC_NORMAL: return 'n'; case ALLOC_ANYWHERE: return 'a'; default: return 'i'; } Isn't that a conflict, or am I reading this wrong? BTW I am not a professional programmer nor do I play one on TV. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: A bug in report.c? WAS: [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page 2007-03-26 22:47 ` A bug in report.c? WAS: " ben scott @ 2007-03-27 1:00 ` Jun'ichi Nomura 2007-03-27 6:48 ` [linux-lvm] LVM2 problem, volume group seems to dissapear Maciej Słojewski 0 siblings, 1 reply; 8+ messages in thread From: Jun'ichi Nomura @ 2007-03-27 1:00 UTC (permalink / raw) To: LVM general discussion and development, Alasdair Kergon Hi, ben scott wrote: > The following lines in report.c seems to show that (c) will become (C) if the > lv is locked: ... > That is also what the man page claims. However the start of report.c show > this: > > switch (alloc) { > case ALLOC_CONTIGUOUS: > return 'c'; > case ALLOC_CLING: > return 'C'; ... > Isn't that a conflict, or am I reading this wrong? BTW I am not a professional > programmer nor do I play one on TV. It's a bug. I added the cling allocation policy and assigned 'C' to it without checking the capitalization part of the report function... Thanks for finding it. Alasdair, Sorry about this bug. IMO, 'C' for ALLOC_CLING should be changed to other letter since it's added after the capitalization. It inevitably introduces possible compatibility issues for existing user of attr field, however. Thanks, -- Jun'ichi Nomura, NEC Corporation of America ^ permalink raw reply [flat|nested] 8+ messages in thread
* [linux-lvm] LVM2 problem, volume group seems to dissapear 2007-03-27 1:00 ` Jun'ichi Nomura @ 2007-03-27 6:48 ` Maciej Słojewski 2007-03-28 19:57 ` Dave Wysochanski 0 siblings, 1 reply; 8+ messages in thread From: Maciej Słojewski @ 2007-03-27 6:48 UTC (permalink / raw) To: 'LVM general discussion and development' Dear Group, I don't have any idea what happened. Yesterdany after routine power on which is scheduled for my machine twice a day (power saving), LVM2 volumes were not detected by system. For security system all data of critical importance are stored on separate software raid (mdm), managed by LVM2 driver. I wonder how to recover the data. What system said during boot up procedure: Fsck.ext3: No such file or directory while trying to open /dev/mapper/pv-zasoby1 /dev/mapper/pv-zasoby1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: E2fsck -b 8193 <device> (...) The same info was displayed about the other pv created volumes. (...) Fsck died with exit status 8 [fail] * File system check failed A log is being saved in /var/log/fsck/checkfs if that location is writable. Please repair the file system manually. Please repair the file system manually * A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. Give root password for maintenance (or type Control-D to continue) Some info about my system: maciej@gucek2:~$ sudo lvmdiskscan Password: Logging initialised at Mon Mar 26 23:03:53 2007 Set umask to 0077 Wiping cache of LVM-capable devices /dev/ram0 [ 64,00 MB] /dev/md0 [ 74,53 GB] LVM physical volume /dev/evms/hde1 [ 101,94 MB] /dev/ram1 [ 64,00 MB] /dev/hde1 [ 101,94 MB] /dev/evms/hde2 [ 1,87 GB] /dev/ram2 [ 64,00 MB] /dev/hde2 [ 1,87 GB] /dev/evms/hde3 [ 24,99 GB] /dev/ram3 [ 64,00 MB] /dev/hde3 [ 24,99 GB] /dev/evms/hde4 [ 28,94 GB] /dev/ram4 [ 64,00 MB] /dev/hde4 [ 28,94 GB] /dev/ram5 [ 64,00 MB] /dev/ram6 [ 64,00 MB] /dev/ram7 [ 64,00 MB] /dev/ram8 [ 64,00 MB] /dev/ram9 [ 64,00 MB] /dev/ram10 [ 64,00 MB] /dev/ram11 [ 64,00 MB] /dev/ram12 [ 64,00 MB] /dev/ram13 [ 64,00 MB] /dev/ram14 [ 64,00 MB] /dev/ram15 [ 64,00 MB] 0 disks 24 partitions 0 LVM physical volume whole disks 1 LVM physical volume Wiping internal VG cache maciej@gucek2:~$ sudo vgdisplay Logging initialised at Mon Mar 26 23:04:38 2007 Set umask to 0077 Finding all volume groups Finding volume group "sys" --- Volume group --- VG Name sys System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 74,53 GB PE Size 4,00 MB Total PE 19079 Alloc PE / Size 0 / 0 Free PE / Size 19079 / 74,53 GB VG UUID l8ADwh-VTnb-qJa1-3Vdg-CX1J-TaSK-kp3nNY Wiping internal VG cache lvm> version LVM version: 2.02.06 (2006-05-12) Library version: 1.02.07 (2006-05-11) Driver version: 4.6.0 maciej@gucek2:~$ uname -r 2.6.17-11-386 # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # /dev/hde3 -- converted during upgrade to edgy UUID=d6738631-13a8-4593-a89b-b51803d16ee3 / ext3 defaults,errors=remount-ro 0 1 # /dev/hde1 -- converted during upgrade to edgy UUID=87fecd19-1110-46b1-be4c-4f8c20370bee /boot ext3 defaults 0 2 /dev/mapper/pv-boot /media/mapper_pv-boot ext3 defaults 0 2 /dev/mapper/pv-home /media/mapper_pv-home ext3 defaults 0 2 /dev/mapper/pv-root /media/mapper_pv-root ext3 defaults 0 2 /dev/mapper/pv-zasoby1 /media/mapper_pv-zasoby1 ext3 defaults 0 2 /dev/mapper/pv-zasoby2 /media/mapper_pv-zasoby2 ext3 defaults 0 2 # /dev/hde2 -- converted during upgrade to edgy UUID=2eddb05e-61a2-4639-9cd3-0c4ab948abd3 none swap sw 0 0 /dev/mapper/pv-swap none swap sw 0 0 /dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/hdc /media/cdrom1 udf,iso9660 user,noauto 0 0 I tried to do vgcfgrestore as I have backup and archive subfolders in /etc/lvm: maciej@gucek2:~$ sudo vgcfgrestore -f /etc/lvm/archive/pv_00000.vg -n pv0 /dev/md0 -t Password: Logging initialised at Mon Mar 26 23:20:00 2007 Set umask to 0077 Test mode: Metadata will NOT be updated. Wiping cache of LVM-capable devices Couldn't find device with uuid 'z93Y68-sV42-coHo-5RxV-WnC8-UFhj-D490Jn'. Couldn't find all physical volumes for volume group pv. Restore failed. Test mode: Wiping internal cache Wiping internal VG cache Wiping internal VG cache I've no idea what to do next. Please give detailed clues, if possible. Kind regards, Maciej S�ojewski (mslonik) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] LVM2 problem, volume group seems to dissapear 2007-03-27 6:48 ` [linux-lvm] LVM2 problem, volume group seems to dissapear Maciej Słojewski @ 2007-03-28 19:57 ` Dave Wysochanski 0 siblings, 0 replies; 8+ messages in thread From: Dave Wysochanski @ 2007-03-28 19:57 UTC (permalink / raw) To: LVM general discussion and development On Tue, 2007-03-27 at 08:48 +0200, Maciej SÅ‚ojewski wrote: > Dear Group, > > I don't have any idea what happened. Yesterdany after routine power on which > is scheduled for my machine twice a day (power saving), LVM2 volumes were > not detected by system. For security system all data of critical importance > are stored on separate software raid (mdm), managed by LVM2 driver. I wonder > how to recover the data. > > What system said during boot up procedure: > > Fsck.ext3: No such file or directory while trying to open > /dev/mapper/pv-zasoby1 > /dev/mapper/pv-zasoby1: > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 filesystem > (and not swap or ufs or something else), then the superblock is corrupt, and > you might try running e2fsck with an alternate superblock: > E2fsck -b 8193 <device> > (...) > The same info was displayed about the other pv created volumes. > (...) > Fsck died with exit status 8 [fail] > > * File system check failed > A log is being saved in /var/log/fsck/checkfs if that location is writable. > Please repair the file system manually. > > Please repair the file system manually > > * A maintenance shell will now be started. > CONTROL-D will terminate this shell and resume system boot. Give root > password for maintenance (or type Control-D to continue) > > > > Some info about my system: > maciej@gucek2:~$ sudo lvmdiskscan > Password: > Logging initialised at Mon Mar 26 23:03:53 2007 > > Set umask to 0077 > Wiping cache of LVM-capable devices > /dev/ram0 [ 64,00 MB] > /dev/md0 [ 74,53 GB] LVM physical volume > /dev/evms/hde1 [ 101,94 MB] > /dev/ram1 [ 64,00 MB] > /dev/hde1 [ 101,94 MB] > /dev/evms/hde2 [ 1,87 GB] > /dev/ram2 [ 64,00 MB] > /dev/hde2 [ 1,87 GB] > /dev/evms/hde3 [ 24,99 GB] > /dev/ram3 [ 64,00 MB] > /dev/hde3 [ 24,99 GB] > /dev/evms/hde4 [ 28,94 GB] > /dev/ram4 [ 64,00 MB] > /dev/hde4 [ 28,94 GB] > /dev/ram5 [ 64,00 MB] > /dev/ram6 [ 64,00 MB] > /dev/ram7 [ 64,00 MB] > /dev/ram8 [ 64,00 MB] > /dev/ram9 [ 64,00 MB] > /dev/ram10 [ 64,00 MB] > /dev/ram11 [ 64,00 MB] > /dev/ram12 [ 64,00 MB] > /dev/ram13 [ 64,00 MB] > /dev/ram14 [ 64,00 MB] > /dev/ram15 [ 64,00 MB] > 0 disks > 24 partitions > 0 LVM physical volume whole disks > 1 LVM physical volume > Wiping internal VG cache > > maciej@gucek2:~$ sudo vgdisplay > Logging initialised at Mon Mar 26 23:04:38 2007 > > Set umask to 0077 > Finding all volume groups > Finding volume group "sys" > --- Volume group --- > VG Name sys > System ID > Format lvm2 > Metadata Areas 1 > Metadata Sequence No 1 > VG Access read/write > VG Status resizable > MAX LV 0 > Cur LV 0 > Open LV 0 > Max PV 0 > Cur PV 1 > Act PV 1 > VG Size 74,53 GB > PE Size 4,00 MB > Total PE 19079 > Alloc PE / Size 0 / 0 > Free PE / Size 19079 / 74,53 GB > VG UUID l8ADwh-VTnb-qJa1-3Vdg-CX1J-TaSK-kp3nNY > > Wiping internal VG cache > > lvm> version > LVM version: 2.02.06 (2006-05-12) > Library version: 1.02.07 (2006-05-11) > Driver version: 4.6.0 > > > maciej@gucek2:~$ uname -r > 2.6.17-11-386 > > # /etc/fstab: static file system information. > # > # <file system> <mount point> <type> <options> > <dump> <pass> > proc /proc proc defaults > 0 0 > # /dev/hde3 -- converted during upgrade to edgy > UUID=d6738631-13a8-4593-a89b-b51803d16ee3 / ext3 defaults,errors=remount-ro > 0 1 > # /dev/hde1 -- converted during upgrade to edgy > UUID=87fecd19-1110-46b1-be4c-4f8c20370bee /boot ext3 defaults 0 2 > /dev/mapper/pv-boot /media/mapper_pv-boot ext3 defaults > 0 2 > /dev/mapper/pv-home /media/mapper_pv-home ext3 defaults > 0 2 > /dev/mapper/pv-root /media/mapper_pv-root ext3 defaults > 0 2 > /dev/mapper/pv-zasoby1 /media/mapper_pv-zasoby1 ext3 defaults > 0 2 > /dev/mapper/pv-zasoby2 /media/mapper_pv-zasoby2 ext3 defaults > 0 2 > # /dev/hde2 -- converted during upgrade to edgy > UUID=2eddb05e-61a2-4639-9cd3-0c4ab948abd3 none swap sw 0 0 > /dev/mapper/pv-swap none swap sw > 0 0 > /dev/hda /media/cdrom0 udf,iso9660 user,noauto > 0 0 > /dev/hdc /media/cdrom1 udf,iso9660 user,noauto > 0 0 > > > > I tried to do vgcfgrestore as I have backup and archive subfolders in > /etc/lvm: > > maciej@gucek2:~$ sudo vgcfgrestore -f /etc/lvm/archive/pv_00000.vg -n pv0 > /dev/md0 -t > Password: > Logging initialised at Mon Mar 26 23:20:00 2007 > > Set umask to 0077 > Test mode: Metadata will NOT be updated. > Wiping cache of LVM-capable devices > Couldn't find device with uuid 'z93Y68-sV42-coHo-5RxV-WnC8-UFhj-D490Jn'. > Couldn't find all physical volumes for volume group pv. > Restore failed. > Test mode: Wiping internal cache > Wiping internal VG cache > Wiping internal VG cache > > > I've no idea what to do next. Please give detailed clues, if possible. > I'm guessing that this line: Couldn't find device with uuid 'z93Y68-sV42-coHo-5RxV-WnC8-UFhj-D490Jn'. is your md device for your missing filesystem volume, /dev/mapper/pv-zasoby1? Your lvm backups (look for the latest one in /etc/lvm/backup) should confirm whether this is the case. If it is, find out why that md device isn't being created (maybe a disk didn't come up?) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-03-28 19:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-03-26 0:11 [linux-lvm] vg attributes (vg_attr) in vgs program don't seem to match the man page ben scott 2007-03-26 9:05 ` Milan Broz 2007-03-26 18:38 ` ben scott 2007-03-26 18:51 ` Alasdair G Kergon 2007-03-26 22:47 ` A bug in report.c? WAS: " ben scott 2007-03-27 1:00 ` Jun'ichi Nomura 2007-03-27 6:48 ` [linux-lvm] LVM2 problem, volume group seems to dissapear Maciej Słojewski 2007-03-28 19:57 ` Dave Wysochanski
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.