Schijfmigratie met LVM – wat hoort waar

De schijfruimte op de mediaserver/NAS die dienstdoet als m’n werkstation, loopt uit vrije opslagruimte.

En al een tijdje uit vrije SATA-aansluitingen. Vanwege het stroomverbruik van een PCIe-SATA-insteekkaart zit die er nog niet in, als dat al ooit komen gaat. Er ligt er een klaar, maar daar _moet_ echt een fannetje op (dus herrie), en het verbruik van ruim 20W (lokale download van huidige versie van het document) is een derde van het huidige systeem.

Kleine schijven vervangen door grotere is een andere optie. Het stroomverbruik zou, met voortgang van de techniek, voor een grotere schijf lager kunnen liggen dan met de kleinere oudere schijf. De oude schijven hebben er bijna tien jaar gebruik op zitten, vrijwel ononderbroken. Ze maken nog geen vervelende geluiden, maar preventief vervangen kan na die tijd geen kwaad.

De schijven die ik beschikbaar heb, zijn:

  • 4TB Seagate; gevuld met incrementele back-ups via Borg-backup.
  • 6TB Seagate; ligt al een tijdje. Het is een SMR-schijf, waarvoor ik eerst host-based SMR wilde uitzoeken. Tot zover geen succes. Blijft dus voorlopig device-based, de firmware beslist dus wat er wanneer hoe op de schijf gezet wordt, en waarzo. Of mij dat gelegen komt, heeft er niets mee te maken.
  • 8TB Western Digital; net nieuw. De directe aanleiding om aan de slag te gaan.
  • 480GB Crucial SSD; uit de laptop van mijn vrouw, nu die wegens plaatsgebrek vervangen is door een 960GB-exemplaar.

Zomaar een schijf erin pluggen gaat niet. In de loop van de tijd is de configuratie qua schijven gewisseld, met als kern een set van drie Western Digital 2GB schijven in RAID5 via mdadmin. Dat geeft een nuttige brutto opslagruimte van 4TB, waar LVM overheen ligt en in de eerste instantie het volledige systeem, op de groei.

Die 4TB zijn ondertussen vrijwel volledig gevuld met foto’s van de afgelopen 25 jaar. Films, video’s, muziek, boeken en ROMs staan niet meer op RAID-ondersteunde LVM. Systeemdirectories nog wel, deels op RAID1 over die drie schijven en deels in LVM op RAID5.

Er zijn zes SATA-poorten ingebouwd op het moederbord, naast de drie 2GB schijven zijn er een 3TB schijf, een kleine SSD voor caching en databases en een HDD met onbekende grootte ingebouwd.

Om een grotere schijf in te kunnen bouwen, moet er eerst eentje uit. Daarnaast wil ik de SSD vervangen door de grotere van 480GB, en de caching op LVM-niveau laten werken. Met de wirwar aan kabels is het niet heel duidelijk welke hardware op welke poort aangesloten is en zijn de schijven niet makkelijk uit de behuizing te trekken. Labels lezen op de schijven gaat dus lastig, schijven matchen met systeemeigenschappen ook.

Bij het vissen naar de huidige configuratie kwam ik wat raars tegen. Een van de 2TB WD Red-schijven deed deed zich voor als 6TB Red. Op internet wel problemen gevonden van mensen wier 6TB als 2TB gezien werd, maar niet andersom.

Ik ben een paar keer bezig geweest met Photorec, bij mogelijk gewiste SD-kaartjes en voor oude defecte schijven. Backups van MBR’s gemaakt, maar niet bewust teruggeschreven. Ik houd op die momenten in de gaten dat ik niet de verkeerde schijf aanspreek, maar je weet maar nooit.

De 6TB SMR-schijf heeft in de machine gezeten. Ik ben onlangs bezig geweest de images van de kleine schijven uit te pluizen, heb ik misschien iets overschreven? Volgens DF zitten er van WD 4 schijven in de kast: 3x Red, in RAID, en 1x de oude Green. Op onderzoek.

De bovenste schijf ligt er los in: de 2,5″ SSD van ~100GB. Zolang ik geen programma’s start waar een database achter zit, en op systeemniveau PostgresSQL en MySQL uitzet, kan ik die loskoppelen: sync disks, umount, hot-unplug power en data.

Met dat uit de weg kan ik het label van de schijf daaronder lezen: 3TB Toshiba, door het systeem herkend als een Hitachi-schijf,Hitachi Deskstar 5K3000. De schijf is van december 2012, dus vlak nadat destijds de 3,5″-productie van Hitachi via WD naar Toshiba ging.

Ik kan de schijf pas hardwarematig loskoppelen nadat de software ontkoppeld is. Onder welke koppelpunten is de data op deze schijf beschikbaar?

Spoorzoeken met mount, df, pvs, vgs, lvs en /etc/fstab. De 3TB schijf is te vinden als /dev/sdf:

root@fractal:~# fdisk -l /dev/sdf
Disk /dev/sdf: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: Hitachi HDS5C303
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D03ED4D8-E7F1-4550-8CEE-762B1263FEBC

Device Start End Sectors Size Type
/dev/sdf1 3563204608 5860532223 2297327616 1.1T Microsoft basic data
/dev/sdf2 2237691904 3563204607 1325512704 632.1G Microsoft basic data
/dev/sdf3 2048 209717247 209715200 100G Linux LVM

Partition table entries are not in disk order.

Vanuit de fysieke partities zijn de physical volumes in LVM te vinden:

root@fractal:~# pvs|grep 'sdf|PV'
PV        VG           Fmt  Attr PSize    PFree
/dev/sdf1 data-nonraid lvm2 a--    <1.07t      0
/dev/sdf2 data-nonraid lvm2 a--   632.05g 273.50g
/dev/sdf3 mailtemp     lvm2 a--  <100.00g <70.00g

Twee volumegroepen op de schijf, data-nonraid en mailtemp. Welke logische volumes er aangemaakt zijn in de volumegroepen is te zien met lvs:

root@fractal:~# lvs|grep 'mailtemp|data-nonraid'
LV       VG           Attr       LSize  ...
homesNR  data-nonraid -wi-a----- 90.00g
muziekNR data-nonraid -wi-ao---- 150.00g
pubNR    data-nonraid -wi-ao---- 100.00g
video    data-nonraid -wi-ao---- <1.09t
mail     mailtemp -wi-ao---- 30.00g

Met vgs is te vinden hoeveel fysieke en logische volumes er bij een volumegroep betrokken zijn. Ter controle of de opsomming hierboven volledig is:

root@fractal:~# vgs |grep 'data-nonraid|mailtemp|VG'
VG           #PV #LV #SN Attr   VSize    VFree
data-nonraid   2   4   0 wz--n-   <1.69t 273.50g
mailtemp       1   1   0 wz--n- <100.00g <70.00g

Drie PV’s in totaal, en 5 LV’s. Dat is wat ik hierboven ook vond. Om het systeem zonder problemen te kunnen starten moeten de partities niet automatisch gekoppeld worden bij het starten van het systeem. Partities die niet automatisch gekoppeld worden, maar nu wel gekoppeld zijn, zijn terug te vinden met mount of df.

root@fractal:~# cat /etc/fstab|grep 'mailtemp\|NR\|video'
/dev/mapper/data--nonraid-video /home/wbk/movies ext4 noatime,noexec 0 2
/dev/mapper/data--nonraid-pubNR /home/wbk/pubNR ext4 noatime,noexec 0 2
/dev/mapper/data--nonraid-muziekNR /home/wbk/music ext4 noatime,noexec 0 2
# video-lv is vervallen omdat alle video's over zijn naar de foto-lv
#/dev/mapper/data-video /home/wbk/video ext4 noexec 0 2
/dev/mapper/mailtemp-mail /var/vmail ext4 defaults 0 2
/home/wbk/pubNR/ftp/ /home/wbk/photos/ftp none bind 0 2
/home/wbk/pubNR/ftp/vsm/foto /var/www/ftp/vsm/foto none bind 0 2
/home/wbk/pubNR/ftp/suirankan/foto /var/www/ftp/suirankan/foto none bind 0 2
/home/wbk/pubNR/ftp/limesco/foto /var/www/ftp/limesco/foto none bind 0 2
/dev/mapper/data--nonraid-homesNR /home/nonraid ext4 noatime,noexec,noauto,noatime,nodiratime 0 2

Reservekopie van /etc/fstab en de mounts van de partities in commentaar zetten.

Het zou voldoende zijn de aangekoppelde bestandssystemen te syncen en los te koppelen voor ik de schijf fysiek loskoppel, maar met draaiende schijven zit me dat minder lekker dan met SSD’s. Dus: machine afsluiten, schijf loskoppelen, reboot, resultaat bekijken.

Print this entry

LVM partitie vergroten en het bestandssysteem mee laten groeien

Op vrijwel alle systemen gebruik ik LVM (LVM2 tegenwoordig) voor het indelen van opslagruimte. Er zijn tegenwoordig allerlei mogelijkheden om flexibel met opslagruimte om te gaan, maar de eenvoudige systemen die ik 1-2-3 kan opnoemen (ZFS, BTRFS), zijn nog niet zo lang beschikbaar voor Linux en heb ik nog maar beperkt gebruikt.

LVM zal op bepaalde punten achterlopen, maar voldoet voor mij prima. In dit geval om een krappe home-directory wat ruimte te geven met lvextend.

Voer de opdracht eerst in testmodus (-t) uit:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
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: Skipping filesystem check for device "/dev/mapper/data-linh" as the filesystem is mounted on /home/linh
/sbin/fsadm failed: 3
Test mode: Skipping archiving of volume group.
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592

Let op ‘/sbin/fsadm failed: 3’, omdat het bestandssysteem aangekoppeld is:

root@linhovo:~# umount /home/linh

Voer de opdracht nu uit zonder -t, om de wijziging aan de logische partitie feitelijk door te voeren en het bestandssysteem te vergroten:

root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -tvrL +30G
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 <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 extents). Test mode: Skipping backup of volume group. Logical volume data/linh successfully resized. Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 274424922112 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-linh 74862592
root@linhovo:~# lvextend /dev/mapper/data-linh /dev/sda3 -vrL +30G
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: 74099/16752640 files (5.8% non-contiguous), 63802054/66998272 blocks
Archiving volume group "data" metadata (seqno 4).
Extending logical volume data/linh to <285.58 GiB Size of logical volume data/linh changed from <255.58 GiB (65428 extents) to <285.58 GiB (73108 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 5). Logical volume data/linh successfully resized. Executing: /sbin/fsadm --verbose resize /dev/data/linh 299450368K fsadm: "ext4" filesystem found on "/dev/mapper/data-linh". fsadm: Device "/dev/mapper/data-linh" size is 306637176832 bytes fsadm: Parsing tune2fs -l "/dev/mapper/data-linh" fsadm: Resizing filesystem on device "/dev/mapper/data-linh" to 306637176832 bytes (66998272 -> 74862592 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/data-linh 74862592
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/data-linh to 74862592 (4k) blocks.
The filesystem on /dev/mapper/data-linh is now 74862592 (4k) blocks long.
root@linhovo:~# df -h /home/linh

UPDATE: ik was blij verrast dat df de ruimte wist te vinden voor de niet-aangekoppelde partitie. Omdat de beschikbare ruimte overeenkwam met wat ik verwachte, heb ik geen acht geslagen op de details.

Nu ik die bekijk, zie ik dat df wel antwoord op mijn vraag gaf, maar als resultaat de partitie toonde waarin het koppelpunt voor /home/linh zich bevind. De partitie is ondertussen verder gevuld en uitgebreid, het verduidelijkt het verhaal niet meer om de juiste output te tonen.

Les voor de volgende keer: vraag niet de vrije ruimte van het mount point op, maar de vrije ruimte van de partitie:

root@linhovo:~# df -h /dev/mapper/data-linh
"partition not mounted" (or something of that order)

Print this entry