Re: Can't work normally after attaching disk volumes originally in a VG on another machine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zdenek Kabelac schreef op 28-03-2018 0:17:

Hi

This is why users do open BZ if they would like to see some enhancement.

Normally cache is integral part of a volume - so it's partially
missing - whole volume is considered to be garbage.

But in 'writethrough' mode there could be likely possible better recovery.

Of course this case needs usability without --force.

So please open  RFE BZ for this case.

It goes into the mess I usually get myself into; if you "dd copy" the disk containing the origin volume before uncaching it, and then go to some live session where you only have the new backup copy, but you want to clean up its LVM,

then you now must fix the VGs in isolation of the cache; I suppose this is just the wrong order of doing things, but as part of a backup you don't really want to uncache first, as that requires more work to get it back to normal after.

So you end up in a situation where the new origin copy has a reference to the cache disk --- all of this assumes writethrough mode --- and you need to clear that reference.

However, you cannot, or should not, attach the cache disk again; it might get effected, and you don't want that, you want it to remain in its pristine state.

Therefore, you are now left with the task of removing the cache from the VG, because you cannot actually run vgimportclone while the cache disk is missing.

The obvious solution is to *also* clone the cache disk and then run operations on the combined set, but this might not be possible.

Therefore, all that was left was:

  vgreduce --remove-missing --force
  cd /etc/lvm/archive
  cp <latest backup> /etc/lvm/backup/<vg>
  cd /etc/lvm/backup
  vi <vg>
  " remove cache PV, and change origin to regular linear volume, and add
  " the visible tag

  vgcfgrestore <vg>

  # presto, origin is restored as regular volume without the cache

  vgimportclone -i <vg> <bla>

  # now have distinct volume group, VG UUID and PV UUID

So the problem is making dd backups of origin, perhaps dd backups should be avoided, but for some purposes (such as system migration) file copies are just

more work

in general, and can complicate things as well, for instance if there are NTFS partitions or whatnot.

And disk images can be nice to have, in any case.

This was the use case basically.

_______________________________________________
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/



[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux