On Mon, 11 Oct 2010, Jörg Stephan wrote:
> > I believe your problem is with your SAN, not LVM (you did mention using
> > iSCSI). I'm talking about SAN snapshots, not LVM snapshots (although the
> > SAN server could very well use LVM underneath). The SAN volumes have no
> > names, just LUNs. At boot, they are searched for a matching UUID, just
> > like directly attached physical volumes. When taking a SAN snapshot
> > (clone), the UUID of the clone is the same as the original, whether a
> > filesystem or VG is on the SAN LUN.
>
> Okay, but we dont use SAN snapshots, we use an lvcreate --snapshot on
> the client. So the storage just dont know about them.
>
> What happens is, we lv snapshot a volume, mount it copy the data to the
> new volume we create after snapshooting the source, remove the old
> snapshot and turning of the new machine. It rans about half an year,
> gets stoped, and after it turning on again the lvm data on the iscsi
> volume is last cahnged on the 23 februar 2010, even if the snapshot was
> made much earlier.
If the contents of (50% of) your SAN disks have reverted, then your issue
is with SAN (iSCSI is a SAN protocol), not with LVM.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
_______________________________________________
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/