Thanks for responding.
I think you're right about why we're getting the message on boot up. We definitely don't have any dm modules in our initrd.
However, I have verified that just the act of rebooting with a snapshot in place doesn't cause the snapshot to become invalid.
One thing that I failed to mention before is that so far the cases where we've seen this problem are also resyncing md mirrors on boot up. I have verified that the resyncing alone doesn't cause the invalidation. A fellow engineer is working on replicating the scenario even closer.
Cheers,
Rob
On Wed, Jul 2, 2008 at 11:42 AM, Jonathan Brassow <jbrassow@redhat.com> wrote:
It sounds like the module needed by device-mapper to support snapshots is not loaded when it is needed. (Perhaps the module - dm-snapshot - is not in your initrd image?)
After step 3, but before step 4, try doing a 'dmsetup table' to see if things are properly mapped. A 'dmsetup status' wouldn't hurt either...
Certainly, there should never be a kernel oops... It's tough for me to say whether this bug is already fixed - given the age of your kernel.
brassow
On Jul 1, 2008, at 4:10 PM, Rob West wrote:
_______________________________________________Does anyone know of ways that snapshots can become invalid other than by writing more to the origin than the COW device can hold?
The reason I ask is that we're having cases where a snapshot is becoming invalid, but we are very skeptical that it is due to overfilling. The size of the origin is 83G, and the size of the snapshot is 8G.
Here's what little we can tell from the logs:
1. Backup script creates a snapshot and starts copying data from it.
2. Before backup is finished (and thus, snapshot removed), the user reboots.
3. On reboot, we get the following message which seems to be normal for this kernel:
kernel: device-mapper: table: 253:2: snapshot-origin: unknown target type
4. About 23 hours later, the backup script tries to create the snapshot again but fails b/c it's still there.
5. The backup script tries to clean up by removing the snapshot, but lvremove causes a kernel oops because the snapshot is invalid. (We have identified a potential patch for this, but are trying to figure out why the snapshot was invalid in the first place.)
The kernel we're using is based off of Fedora 6 (2.6.18-1.2849).
Not sure whether it matters, but device-mapper is version 1.02.07 release 4.0.RHEL4 and lvm2 is version 2.02.06 release 6.0.RHEL4.
Thanks for any help,
Rob
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/
_______________________________________________
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/
_______________________________________________ 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/
