[linux-lvm] howto avoid initializing a particular volume-group at boot time?

Zdenek Kabelac zkabelac at redhat.com
Tue Jan 8 09:58:42 UTC 2013


Dne 1.1.2013 23:07, Tom Assmuth napsal(a):
> hi and best wishes for the new year!
>
> Let me describe my scenario: I have a big volume group (let's say:
> /dev/vgbig/lv[1-9]) with a lot of snapshots in it and not used very
> often. Another volume group (/dev/vgsmall/lv[1-9]) contains data for
> normal use.
>
> Because of initializing /dev/vgbig/ at boot time the machine becomes
> usable after about 12h (twelve!)

I've some feeling there is big miss usage of snapshots here.

The 'old-style' snapshot was designed as a 'temporary' short time usable image 
of filesystem - i.e. for making backup, so the filesystem will not
change and backup will be consistent.

It seems like you are using snapshosts 'instead' of backups.

However if you have snapshot with storage size in hundreds of GB,
you need to realize, whole snapshots needs to be parsed (read in memory),
to figure out the block remapping layout (yep, there is very very simple
format to store this information, since design was for short livetime).

There are no plans to improve/fix this logic in old-style snapshots.

You may look at thin provisioning support for more advanced way how to
use multiple long-time living snapshots of the LV.

But also I'd probably suggest to use 'real' backups instead of
multiple snapshost - since the performance must be horrible.


> It would be ok if the machine would boot with /dev/vgsmall
> initialized, would do it's normal duty and in an late initscript would
> initialize /dev/vgbig/ (vgchange -ay /dev/vgbig/ ) It would be ok to
> wait now, because i could do my normal work.
>
> I thougt about a rule in /etc/lvm/lvm.conf, but i am not sure how to
> write it.


Fix your boot initramdisk and avoid calling  'vgchange -ay',
and replace it with code to properly activate only needed VG.

(Also try to replace those huge snapshots with backups and delete them - you 
will see a major jump in performance).

Zdenek




More information about the linux-lvm mailing list