by wbk | 18 april 2021 20:35
Met de vorige uitbreidingen (lvextend) waren de laatste restjes vrije ruimte in de data-volumegroep benut. Op de system-volumegroep was nog wel iets ruimte, maar dat hield ook niet over.
De SSD van 480GB is daarom vervangen door eentje van 960GB. De oude van 480GB wordt cache in de desktop/NAS/mediaserver, die wordt misschien als tweede node in een Proxmox configuratie opgenomen.
Eerst de schijf verwisselen. De laptop heeft ruimte voor twee SATA-apparaten, maar een van de aansluitingen is defect. Kopieren leek me het handigste aan de USB3-poorten van de desktop.
De beide SSD’s heb ik aangesloten via SATA<>USB3-adapters, maar bij het aansluiten op de USB3-poorten op de desktop kwamen foutmeldingen, bij een test op USB2 niet. Daarom via de USB2-poorten aangesloten. Wel langzamer, maar 480Gb/s zou in een datarate van zo’n 35-45MB/s moeten vertalen, acceptabel voor ~450GB aan data.
pv > /dev/sdh > /dev/sdg
De datarate viel me tegen, fluctuerend tussen 1 en 6 MB/s, met uitschieters naar boven en beneden. De volgende dag, na ruim 12 uur, was krap 10% gekopieerd, met als prognose nog ruim een dag. Dat was een stuk slechter dan ik had verwacht, ook met USB2.
Daarom toch intern aangesloten. Boot met beide schijven werkte niet: er was al voldoende gekopieerd om twee schijven met identieke LVM-configuratie te hebben, dat gaf problemen.
Dus: boot zonder de beide SSD’s, daarna hotplug aan de interne SATA.
Vervolgens gaf het kopieren een totaal ander beeld, bij aanvang ruim 250MB/s. Ik meen dat de SATA-aansluitingen op het moederbord SATA2 zijn, dus met een maximum bandbreedte van 300MB/s. Met de gemeten snelheid zou het een half uur duren om de volledige schijf te kopieren.
Uiteindelijk is de performance nog aardig ingezakt, tot rond 15MB/s en dips rond 5MB/s, maar na 2 uur was de kopieerslag klaar.
Op de server heb ik nog een LVM-partitie aan de SSD toegevoegd. Het uitbreiden van de volumegroep heb ik nog niet gedaan, omdat op de server een volumegroep bestaat met dezelfde naam.
Na het inbouwen van de nieuwe SSD in de laptop, boot die zonder problemen. Aan de slag!
Er zijn twee volumegroepen, en aan elk daarvan is een fysiek volume (partitie) toegekend:
root@linhovo:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a-- 51.47g 27.89g
/dev/sda3 data lvm2 a-- 347.65g 136.00m
De volumegroepen zijn net zo groot als de som van de toegewezen partities:
root@linhovo:~# vgs
VG #PV #LV #SN Attr VSize VFree
data 1 2 0 wz--n- 347.65g 136.00m
system 1 4 0 wz--n- 51.47g 27.89g
Met vgextend kan volumegroep uitgebreid worden met een partitie. Er zijn zes partities:
root@linhovo:~# fdisk -l Disk /dev/sda: 894.3 GiB, 960197124096 bytes, 1875385008 sectors Disk model: Intenso SSD SATA Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: EA98124F-2230-4671-A4B6-C197DAB72AA2 Device Start End Sectors Size Type /dev/sda1 1024000 36863999 35840000 17.1G Linux swap /dev/sda2 36864000 144818175 107954176 51.5G Linux LVM /dev/sda3 247685120 976773119 729088000 347.7G Linux LVM /dev/sda4 2048 352255 350208 171M Linux filesystem /dev/sda5 352256 546815 194560 95M BIOS boot /dev/sda6 976773120 1710776319 734003200 350G Linux LVM Partition table entries are not in disk order.
De laatste partitie, op /dev/sda6, is nieuw. Die wordt aan de data-volumegroep toegevoegd:
root@linhovo:~# vgextend -tv data /dev/sda6
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Wiping signatures on new PV /dev/sda6.
Set up physical volume for "/dev/sda6" with 734003200 available sectors.
Zeroing start of device /dev/sda6.
Writing physical volume data to disk "/dev/sda6".
Physical volume "/dev/sda6" successfully created.
Test mode: Skipping archiving of volume group.
Adding physical volume '/dev/sda6' to volume group 'data'
Failed to find cached info for PV /dev/sda6.
PV /dev/sda6 cannot be added to VG data.
… Failed to find cached info for PV /dev/sda6, cannot be added. Ik weet nog niet waar de gecachte info vandaan zou moeten komen, maar ik had verwacht een pv..-opdracht te moeten geven voordat ik een vg…-opdracht kon geven.
Met pv-tab-tab krijg ik een veelbelovend lijstje:
root@linhovo:~# pv pvchange pvck pvcreate pvdisplay pvmove pvremove pvresize pvs pvscan root@linhovo:~# pvcreate --help (hulp) root@linhovo:~# pvcreate /dev/sda6 Physical volume "/dev/sda6" successfully created.
Daarna kan de volumegroep uitgebreid worden met het gedefinieerde fysieke volume:
root@linhovo:~# vgextend -tv data /dev/sda6 TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated. Wiping signatures on new PV /dev/sda6. Test mode: Skipping archiving of volume group. Adding physical volume '/dev/sda6' to volume group 'data' Volume group "data" will be extended by 1 new physical volumes Test mode: Skipping backup of volume group. Volume group "data" successfully extended
Het resultaat:
root@linhovo:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a-- 51.47g 27.89g
/dev/sda3 data lvm2 a-- 347.65g 136.00m
/dev/sda6 lvm2 --- 350.00g 350.00g
Ongebruikte LVM-ruimte op sda6. Geen volume toegewezen. Dat nu met vgextend:
root@linhovo:~# vgextend -tv data /dev/sda6
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Wiping signatures on new PV /dev/sda6.
Test mode: Skipping archiving of volume group.
Adding physical volume ‘/dev/sda6’ to volume group ‘data’
Volume group “data” will be extended by 1 new physical volumes
Test mode: Skipping backup of volume group.
Volume group “data” successfully extended
Nu voor het echie, zonder -t:
root@linhovo:~# vgextend -v data /dev/sda6
Wiping signatures on new PV /dev/sda6.
Archiving volume group “data” metadata (seqno 6).
Adding physical volume ‘/dev/sda6’ to volume group ‘data’
Volume group “data” will be extended by 1 new physical volumes
Creating volume group backup “/etc/lvm/backup/data” (seqno 7).
Volume group “data” successfully extended
En ter controle:
root@linhovo:~# vgs
VG #PV #LV #SN Attr VSize VFree
data 2 2 0 wz–n- <697.65g <350.13g
system 1 4 0 wz–n- 51.47g 27.89g
Nu het logische volume uitbreiden, eerst de huidige vrije ruimte ter vergelijking:
root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/data-linh ext4 284G 264G 5.9G 98% /home/linh
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log
De uit te breiden partitie is /home/linh, die dus eerst loskoppelen:
root@linhovo:~# umount /dev/mapper/data-linh
umount: /home/linh: target is busy.
root@linhovo:~# lsof |grep /home/linh
(lijstje)
Met htop filteren op user = linh, en de programma’s afsluiten met k. De grafische interfase op de laptop staat al uit, met service sddm stop, dus er kan geen gebruikersdata verloren gaan.
Nog eens loskoppelen:
root@linhovo:~# umount /dev/mapper/data-linh
root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log
root@linhovo:~# mount|grep mapper
/dev/mapper/system-root on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/system-usr on /usr type ext4 (rw,relatime)
/dev/mapper/data-home on /home type ext4 (rw,relatime)
/dev/mapper/system-var on /var type ext4 (rw,relatime)
/dev/mapper/system-log on /var/log type ext4 (rw,relatime)
Nu het logische volume uitbreiden, eerst in test-modus:
root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda6 -tvrL +330G
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Executing: /sbin/fsadm –dry-run –verbose check /dev/data/linh
fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”.
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-linh
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <618.58 GiB Size of logical volume data/linh changed from <288.58 GiB (73876 extents) to <618.58 GiB (158356 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm –dry-run –verbose resize /dev/data/linh 648626176K fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”. fsadm: Device “/dev/mapper/data-linh” size is 309858402304 bytes fsadm: Parsing tune2fs -l “/dev/mapper/data-linh” fsadm: Resizing filesystem on device “/dev/mapper/data-linh” to 664193204224 bytes (75649024 -> 162156544 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 162156544
Dan weer in het echt:
root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda6 -vrL +330G
Executing: /sbin/fsadm –verbose check /dev/data/linh
fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”.
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Executing fsck -f -p /dev/mapper/data-linh
fsck from util-linux 2.33.1
linh: 79452/18915328 files (6.3% non-contiguous), 70513450/75649024 blocks
Archiving volume group “data” metadata (seqno 7).
Extending logical volume data/linh to <618.58 GiB Size of logical volume data/linh changed from <288.58 GiB (73876 extents) to <618.58 GiB (158356 extents). Loading table for data-linh (254:3). Suspending data-linh (254:3) with device flush Resuming data-linh (254:3). Creating volume group backup “/etc/lvm/backup/data” (seqno 8). Logical volume data/linh successfully resized. Executing: /sbin/fsadm –verbose resize /dev/data/linh 648626176K fsadm: “ext4” filesystem found on “/dev/mapper/data-linh”. fsadm: Device “/dev/mapper/data-linh” size is 664193204224 bytes fsadm: Parsing tune2fs -l “/dev/mapper/data-linh” fsadm: Resizing filesystem on device “/dev/mapper/data-linh” to 664193204224 bytes (75649024 -> 162156544 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-linh 162156544
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-linh to 162156544 (4k) blocks.
The filesystem on /dev/mapper/data-linh is now 162156544 (4k) blocks long.
In test-modus duurde het nauwelijks een seconde, de feitelijke transactie duurde vijf keer zo lang. Dus na een seconde of vijf:
root@linhovo:~# fdisk -l /dev/mapper/data-linh
Disk /dev/mapper/data-linh: 618.6 GiB, 664193204224 bytes, 1297252352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Bestandssysteem aankoppelen….
root@linhovo:~# mount /dev/mapper/data-linh
… en de grootte verifieren:
root@linhovo:~# df -hTt ext4
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/system-root ext4 6.5G 142M 6.0G 3% /
/dev/mapper/system-usr ext4 9.4G 7.2G 1.7G 82% /usr
/dev/mapper/data-home ext4 58G 17G 39G 31% /home
/dev/mapper/system-var ext4 6.4G 972M 5.1G 16% /var
/dev/mapper/system-log ext4 922M 30M 829M 4% /var/log
/dev/mapper/data-linh ext4 608G 264G 315G 46% /home/linh
De vrije ruimte is toegenomen met 310G, er zit dus zo’n 8% overhead in LVM. Van 98% gevuld zonet naar 46% na het uitbreiden van de partitie.
Grafische interface weer aanzetten…
root@linhovo:~# service sddm start
en na inloggen de ruimte in de browser controleren:
Source URL: https://online.osba.nl/blog/2021/04/18/schijf-vervangen-lvm-volume-group-uitbreiden/
Copyright ©2024 Open Source, Boudewijns angle unless otherwise noted.