Re: Umzug von Daten
Am Donnerstag, 2. Februar 2017, 18:16:35 CET schrieb Siegfrid Brandstätter:
> Hallo,
>
> Am Donnerstag, 2. Februar 2017, 16:29:23 schrieb Martin Steigerwald:
> > Am Donnerstag, 2. Februar 2017, 14:57:17 CET schrieb Siegfrid
Brandstätter:
> > > Hallo,
> > >
> > > Am Freitag, 27. Januar 2017, 22:45:34 schrieb Peter Ludikovsky:
> > > > Am 26.01.2017 um 22:30 schrieb Siegfrid Brandstätter:
> > > > > Hallo,
> > > > >
> > > > > Wie gehe ich da richtig vor? Danke schon im voraus!
> > > >
> > > > Indem du LVM richtig nutzt:
> > > > 1) Mit vgextend die alte Volume Group erweitern
> > > >
> > > > vgextend xvt1 /dev/<ssd>
> > > >
> > > > 2) Mit pvmove die Daten auf die SSD schieben
> > > >
> > > > pvmove --atomic --name Daten /dev/sdb8 /dev/<ssd>
> > >
> > > Heute habe ich endlich dafür genügend Zeit um dies durchzuführen. Dabei
> > > ergibt sich aber nun folgendes Problem. Die /Daten auf /dev/sdb8 sind
> > > ja
> > > derzeit in keinem PV sondern auf einer normalen Partition.
> > >
> > > # vgextend xvt1 /dev/dm-12
> > >
> > > Physical volume
> > > "/dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-33ddd902df23"
> > >
> > > successfully created
> > >
> > > Volume group "xvt1" successfully extended
> > >
> > > Daher anscheinend diese Meldung:
> > > # pvmove --atomic --name Daten /dev/sdb8 /dev/dm-12
> > >
> > > Physical volume /dev/sdb8 not found
> > >
> > > > Damit werden die Daten innerhalb der Volume Group auf die SSD
> > > > verschoben
> > > > ohne dass du sonst irgendwelche Änderungen machen musst, oder
> > > > irgendwas
> > > > außer Betrieb nehmen.
> > >
> > > Gilt dies also nur wenn die Daten auch schon auf einer Festplatte mit
> > > LVM
> > > liegen?
> >
> > pvmove benötigt eine Physical Volume. Kein Physical Volume, kein pvmove.
> >
> > So oder so würde ich da einfach rsync -aAHXS oder so nehmen, um die Daten
> > rüberzukopieren. Warum? Weil pvmove auch den unbelegten Speicherplatz in
> > der Logical Volume mitkopieren würde. Zumindest denke ich das, da mich
> > wundern würde, wenn LVM sich merkt, in welche Logical / Physical Extents
> > es schon hingeschrieben hat, oder dabei gar fstrim berücksichtigt anstatt
> > es nur an das darunterliegende Gerät weiterzugeben.
> >
> > Auch mehrere Laufwerke in eine VG zu packen würde ich mit Vorsicht
> > genießen. Das letzte Mal als ich das probierte, und dann mal testweise
> > eine
> > Festplatte entfernte, fand LVM das nicht so lustig, obwohl ich daran
> > dachte,
> > sicherzustellen, dass eine LV entweder komplett auf einem oder auf einem
> > anderen PV ist.
>
> Nach dem:
> > > # vgextend xvt1 /dev/dm-12
> > >
> > > Physical volume
> > > "/dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-33ddd902df23"
> > >
> > > successfully created
> > >
> > > Volume group "xvt1" successfully extended
>
> Erhalte ich nun beim Versuch diese verschlüsselte Platte zu mounten dies:
>
> # mount /dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-d5ddd902df23 /mnt
> mount: unknown filesystem type 'LVM2_member'
>
> Es ist wohl am besten wenn ich den Befehl :" vgextend xvt1 /dev/dm-12”
> wieder rückgängig machen würde, aber wie?
vgreduce, aber ob das am besten ist, weiß ich gerade nicht, da ich den Thread
nicht von Anfang an verfolgt habe (und somit meine Idee mit rsync -aAHXS
möglicherweise nicht zielführend war).
Ciao,
--
Martin
Reply to: