Bug 604767

Is it possible to deactivate VG50 and reactivate when the machine is up?  Then you could collect the results of 'vgchange -ay -vvvv VG50' and attach them.  As it is, the log collection you posted doesn't give any more information.  It may also be possible to collect extra information by setting the log level to '3' - the highest setting.

Created attachment 424578 [details]
output of dmesg command reduced to dracut output

Hi, 

I cannot deactivate VG50 because it holds the rootfs (/). I modified lvm.conf to increase the log level but no more information. I have attached the vgchange part of the boot process. I have noticed that after each
dracut: Loading VG50-iscsi1_20100530 table (253:18)
the freezes for some time (I made comments in the file, search for "---").

I also attach my lvm.conf

Created attachment 424579 [details]
lvm.conf

hmmm, ok.  You may be forced to update the initrd after making changes to lvm.conf... after all, the system cannot see lvm.conf when the file system isn't there yet.

Perhaps some information about the LVs and VGs on the system?  We may be able to try a reproduction if we have enough information.

Created attachment 424866 [details]
outpus of dmesg,pvs,vgs,lvs with highest verbosity

I have managed to get verbose = 3.

Here is the result.
The system freezes after
1. dracut: dm reload (253:18) NF [16384]
2. dracut: dm reload (253:12) NF [16384]
3. dracut: dm reload (253:15) NF [16384]

I believe I have the same problem, and a more extreme case.  When activating 
a VG, it hangs for a couple of minutes after printing "dm reload" for each 
snapshot.  We have a lot of LVs, with a lot of snapshots, so the machine
takes about 90 minutes to boot.



ioctl/libdm-iface.c:1702         dm create clones-c24_s1_snap2-cow LVM-xTknbZ2teX4F1abPCxOOwXiiIrj64dx0kf2agS7V0pyl1R8yJmg3xGH0a89DLLpI-cow NF   [16384]
#libdm-common.c:763         clones-c24_s1_snap2-cow: Stacking NODE_ADD (253,92) 0:6 0660
#libdm-deptree.c:1524     Loading clones-c24_s1_snap2-cow table (253:92)
#libdm-deptree.c:1470         Adding target to (253:92): 0 2621440 linear 8:48 2559737984
#libdm-deptree.c:1470         Adding target to (253:92): 2621440 11141120 linear 8:48 2622652544
#libdm-deptree.c:1470         Adding target to (253:92): 13762560 15728640 linear 8:48 3500441728
#libdm-deptree.c:1470         Adding target to (253:92): 29491200 1310720 linear 8:48 3126886528
#ioctl/libdm-iface.c:1702         dm table   (253:92) OF   [16384]
#ioctl/libdm-iface.c:1702         dm reload   (253:92) NF   [16384]
#libdm-deptree.c:1564         Table size changed from 0 to 30801920 for clones-c24_s1_snap2-cow
#libdm-deptree.c:903     Resuming clones-c24_s1_snap2-cow (253:92)
#ioctl/libdm-iface.c:1702         dm resume   (253:92) NF   [16384]
#libdm-common.c:791         clones-c24_s1_snap2-cow: Stacking NODE_READ_AHEAD 256 (flags=1)
#libdm-deptree.c:1196     Creating clones-c24_s1_snap2
#ioctl/libdm-iface.c:1702         dm create clones-c24_s1_snap2 LVM-xTknbZ2teX4F1abPCxOOwXiiIrj64dx0kf2agS7V0pyl1R8yJmg3xGH0a89DLLpI NF   [16384]
#libdm-common.c:763         clones-c24_s1_snap2: Stacking NODE_ADD (253,93) 0:6 0660
#libdm-deptree.c:1524     Loading clones-c24_s1_snap2 table (253:93)
#libdm-deptree.c:1470         Adding target to (253:93): 0 109051904 snapshot 253:90 253:92 P 8
#ioctl/libdm-iface.c:1702         dm table   (253:93) OF   [16384]
#ioctl/libdm-iface.c:1702         dm reload   (253:93) NF   [16384]

How large & full are the snapshot LVs?  At that point it is reading the 'used' part of the snapshot LV to construct the snapshot 'overlay' table in memory.

> How large & full are the snapshot LVs? 

I failed to note other examples, but the one LV which I know was 
slow us as follows:

 LV Name                /dev/clones/c24_s1_snap2
  VG Name                clones
  LV UUID                kf2agS-7V0p-yl1R-8yJm-g3xG-H0a8-9DLLpI
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/clones/c24_s1
  LV Status              available
  # open                 0
  LV Size                52.00 GB
  Current LE             832
  COW-table size         14.69 GB
  COW-table LE           235
  Allocated to snapshot  82.34% 


> At that point it is reading the 'used' part of the snapshot LV to 
> construct the snapshot 'overlay' table in memory.  

I may be barely qualified enough and just motivated enough to add 
new code to save that information on disk rather than reconstructing 
it with each activation, if someone were kind enough to point me in 
the right direction.  I haven't read the LVM source, but do have a 
pretty good understanding of how it works, I believe.

I should mention most of the other snapshots are not that large.
A more typical example might be about 1/3rd that size:

  LV Size                113.00 GB
  Current LE             1808
  COW-table size         4.19 GB
  COW-table LE           67
  Allocated to snapshot  83.07%

My Snapshots are 10GB in size and filled somewhere between 30%-90%.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

The current snapshot implementation is slow to load.  That won't change.

New implementations are being worked on which will be much faster.