Charles Marcus wrote:
On 5/1/2008 4:30 PM, Gerry Reno wrote:
At least in the case where the snapshot is read-only (LVM1 default,
LVM2 by config?), if the snapshot is lost, invalid, not removed
from VG prior to reboot, when LVM comes back up it should see this
and immediately know that it can just vgreduce VG --removemissing
for the old snapshot. In the case of rw (no LVM1, LVM2 default),
it should be a user choice and LVM should prompt the user at boot
as to whether to remove this old snapshot so it can attempt to
activate the VG. Unless the user knows that there were non-backup
related lvm mods written during the snapshot (eg: pvmove) then the
user will just answer yes and the system should boot. This is how
LVM should operate in this scenario.
If you want your system to do that, update your initrd/initscripts
accordingly to run the appropriate lvm2 commands to do that!
I can certainly do that. But I think this applies in the general case
and should be included as standard behavior in LVM. This is a much
more robust means of dealing with this scenario that having LVM just
refuse to mount the volume when the only issue is a bad snapshot.
Question...
In Gerry's scenario here, if the snapshot volume had NOT been on a ram
disk, would he have had the problem he had or not?
Charles,
Without knowing the exact cause of the hang there is no way to know if
the ramdisk was at issue. I doubt it myself, I ran a whole series of
backups last night using the ramdisk snapshot and everything went fine.
Gerry
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
