[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]