Opened 18 years ago
Closed 9 years ago
#68 closed enhancement (fixed)
LVM log. volumes are not resized using factor which creates problems when restoring
Reported by: | Owned by: | Bruno Cornec | |
---|---|---|---|
Priority: | normal | Milestone: | 3.2.2 |
Component: | mondo | Version: | 2.0.9 |
Severity: | normal | Keywords: | |
Cc: | andree@… |
Description
When mondorestore finds a new disk geometry:
[Main] libmondo-devices.c->get_phys_size_of_drive#1259: /dev/hda --> -1 or 8192 --> 8192 Expanding entries to suit drive /dev/hda (8192 MB) [Main] mondo-prep.c->create_mountlist_for_drive#2777: Creating list of partitions for drive /dev/hda Disk /dev/hda was 38162 MB; is now 8192 MB; factor = 0.214664 Changing /dev/hda2 from 38973690 KB to 8366240 KB Changing /dev/hda1 from 104391 KB to 22408 KB
it computes a factor which is then applied to all physical partitions. But it's NOT applied to Logical volumes, which create a problem if disks are smaller only.
lvm vgchange -a y main --> 0 lvcreate -L 36864m -r 0 -n root main --> 1280 [Main] mondo-prep.c->do_my_funky_lvm_stuff#486: echo "lvm vgchange -a y main" >> /tmp/out.sh... so I'll get creative. lvcreate -L 36864m -r 0 -n root main --> 1 lvm lvcreate -L 960m -r 0 -n swap main --> 0 lvm vgscan --> 0 [Main] mondo-prep.c->do_my_funky_lvm_stuff#549: Closed i-want-my-lvm. Finished doing funky stuff.
Change History (9)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Status: | new → assigned |
---|---|
Type: | defect → enhancement |
The problem is that there is an incoherence the way mondo treats normal FS (resized correctly) and LVM FS (resized incorrectly). Agree that it's an enhancement to bring. Is it possible for 2.2.0 or should we plan it for 2.2.1 ?
comment:3 by , 18 years ago
Well, to tell the truth I think it would be good to unify the way arbitray types of volumes are handled (and thus resized). It shouldn't really matter whether they are plain partitions, RAID volumes or LVM physical or logical volumes. I think they should just be different variations of the same object type requiring different tools to handle them. I hope this is not too esoteric. In that light it would be more 3.0 or beyond stuff.
Could we do something on the quick to extract size information from /tmp/i-want-my-lvm and adjust it? Possibly. I'd probably rewrite the /tmp/i-want-my-lvm file with adjusted size values for this before submitting it for processing to do_my_funky_lvm_stuff(). I'm just not sure whether I'll find the time with all the other stuff going on including my company moving office on the coming weekend. :-( Can we leave this undecided for another two days? (Maybe I get a chance tomorrow or Thursday.)
comment:4 by , 18 years ago
Milestone: | 2.2.0 → 2.2.1 |
---|
I think we have other topics to solve for 2.2.0 first, and I'd prefer your help on these points rather as your time will be limited,and as we try to publish 2.2.0 for an etch compatible timeframe. So I postpone it to 2.2.1 for the moment. Feel free to move it to 3.0.0 if you find that more accurate.
comment:5 by , 18 years ago
Milestone: | 2.2.1 → 2.2.2 |
---|
comment:6 by , 18 years ago
Milestone: | 2.2.2 → 2.2.3 |
---|
comment:7 by , 18 years ago
Milestone: | 2.2.3 → 2.2.4 |
---|
comment:8 by , 18 years ago
Milestone: | 2.2.4 → 3.0.2 |
---|
OK. Won't be in 2.x line I think so moving it to 3.x
comment:9 by , 9 years ago
Milestone: | 4.0.2 → 3.2.2 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Fixed in 3.2.2 !
do_my_funky_lvm_stuff() for LVM stuff and resize_mountlist_proportionately_to_suit_new_drives() for normal disks are currently completely disparate in their approach. do_my_funky_lvm_stuff() reads file /tmp/i-want-my-lvm and runs the lvm commands it contains pretty much verbatimly, so it's actually quite dumb and doesn't really understand what it is doing. resize_mountlist_proportionately_to_suit_new_drives() in contrast is way cleverer, 'knows' the mountlist and utilises resize_drive_proportionately_to_suit_new_drives() to adjust the partition sizes.
Need to look at /tmp/i-want-my-lvm to get a better handle on what we need to do to extract size information which is a prequisite for changing it.
I don't really think this is a defect. It is simply functionality not existing yet. Notwithstanding this, it would certainly be a good one to have.