Where to report bugs?

I failed to locate a definitive location to reports LVM2 bugs. Isn't the Redhat Bugzilla the right place?

If so, what category should LVM bugs go to?

https://bugzilla.redhat.com/enter_bug.cgi

Best regards,
Hannes Dorbath

If you want to use bugzilla rather than this mailing list, file bugs that you find in upstream CVS against:

Product Fedora
Version devel
Component lvm2

Alasdair

[email protected]

OK, if this ML is fine as well, I'll post it here:

Summary is that an active snapshot LV that loses its COW PV and is in the same VG as the origin LV makes the origin LV disappear.

Example:
1. Create 2 PVs. Let's say /dev/sda and /dev/sdb
2. Create a VG with PV /dev/sda named data
3. Create a LV on VG data named origin
4. Extend VG data with PV /dev/sdb
5. Create a snapshot LV of LV origin, in VG data, on PV /dev/sdb, named snap
6. Remove /dev/sdb physically from the system (or disable in BIOS)
7. Reboot
8. Use vgreduce --removemissing to get VG data up again

LV origin is gone and can only be brought back from backup with vgcfgrestore.

lvm 2.02.28
dev-mapper 1.02.22-r1
kernel 2.6.22-r8

Best regards,
Hannes Dorbath

Right. So you're asking for vgreduce --removemissing to be enhanced to consider just removing the snapshot and leaving behind the LV if it possible. Seems reasonable.

The logic that needs improving is in _remove_lv() in tools/vgreduce.c if anyone wants to have a go at fixing it.

                /* Use the origin LV */
                lv = snap_seg->origin;

Perhaps it should have a second variable to hold the origin, and in the following loop only deal with the current cow instead of all of them.

(It needs to handle two cases: origin LV is gone=>loop and remove all snapshots as well as the origin; snapshot LV only is gone=>only remove this snapshot. Maybe push the remove_snapshot code into a separate function then call it from two places for the two different cases, avoiding the loop for the one snapshot only case.)

Alasdair

[email protected]