[LVM] Resize probleem

[maleadt]

Sinds een paar maanden beheer ik mijn harde schijven met LVM. Dat is vlekkeloos verlopen, tot nu. Het resizen (vergroten) van een bepaalde logische partitie wil maar niet lukken...

De software

LVM2, stable versie uit Arch Linux:

code:

[tim@galactica ~]$ pacman -Qs lvm
local/lvm2 2.02.60-2 (base)
    Logical Volume Manager 2 utilities

Stable kernel 2.6.32-7, Arch-version:

code:

[tim@galactica ~]$ uname -a
Linux galactica 2.6.32-ARCH #1 SMP PREEMPT Fri Jan 29 09:10:49 CET 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
[tim@galactica ~]$ pacman -Qs kernel26
local/kernel26 2.6.32.7-1 (base)
    The Linux Kernel and modules

De situatie

1 volume group, "data"

code:

[tim@galactica Desktop]$ sudo vgdisplay /dev/data
  --- Volume group ---
  VG Name               data
  System ID             
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  37
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               4
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               2,86 TiB
  PE Size               4,00 MiB
  Total PE              748784
  Alloc PE / Size       678400 / 2,59 TiB
  Free  PE / Size       70384 / 274,94 GiB
  VG UUID               7ejRqW-ekql-76IP-n8o4-CupX-H65l-G9HyGZ

4 logische partities:

code:

[tim@galactica Desktop]$ sudo lvscan 
  ACTIVE            '/dev/data/video' [1,46 TiB] inherit
  ACTIVE            '/dev/data/software' [500,00 GiB] inherit
  ACTIVE            '/dev/data/muziek' [500,00 GiB] inherit
  ACTIVE            '/dev/data/home' [150,00 GiB] inherit

3 fysieke partities:

code:

[tim@galactica Desktop]$ sudo pvscan 
  PV /dev/sdc1   VG data   lvm2 [1,36 TiB / 0    free]
  PV /dev/sda1   VG data   lvm2 [931,51 GiB / 178,77 GiB free]
  PV /dev/sdb1   VG data   lvm2 [596,17 GiB / 96,17 GiB free]
  Total: 3 [2,86 TiB] / in use: 3 [2,86 TiB] / in no VG: 0 [0   ]

De probleem-partitie in kwestie:

code:

[tim@galactica Desktop]$ sudo lvdisplay /dev/data/video 
  --- Logical volume ---
  LV Name                /dev/data/video
  VG Name                data
  LV UUID                RJamdk-p2ui-xz9a-lbLr-ly1V-YCXP-FF1LCz
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                1,46 TiB
  Current LE             384000
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:0

Het probleem

Omdat mijn video-partitie vol staat, wil ik die resizen. Ik kies ervoor om 250GB toe te voegen, verspreid over /dev/sda1 en /dev/sdb1.

code:

[tim@galactica Desktop]$ sudo lvresize --debug -L +250GB /dev/data/video 
  Extending logical volume video to 1,71 TiB
  device-mapper: resume ioctl failed: Ongeldig argument
  Unable to resume data-video (254:0)
  Problem reactivating video

Dat faalt quasi-onmiddelijk, en lvresize geeft mij de controle terug over de terminal.

Als ik dan een lvdisplay probeer, loopt die helemaal vast en reageert op geen enkele interrupt, zelf geen kill -9 (wat mij doet vermoeden dat er 1 of andere kernel lock vast zit). Na de mislukte lvresize vind ik wat info terug in dmesg:

code:

[tim@galactica Desktop]$ dmesg | tail
[snip]
device-mapper: table: 254:0: sda1 too small for target: start=1578606976, len=374906880, dev_size=1677844481

Ik weet niet in welke eenheid die getallen uitgedrukt staan, maar mijn partitietabel van /dev/sda ziet er alleszins correct uit:

code:

[tim@galactica ~]$ sudo fdisk -l /dev/sda

Schijf /dev/sda: 1000.2 GB, 1000204886016 bytes
255 koppen, 63 sectoren/spoor, 121601 cilinders
Eenheid = cilinders van 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes
Schijf-ID: 0x00037bfd

 Apparaat Opstart   Begin       Einde     Blokken   ID  Systeem
/dev/sda1               1      104441   838922240+  8e  Linux LVM
/dev/sda2   *      104441      104502      489982+  83  Linux
/dev/sda3          104502      104624      979965   82  Linux wisselgeheugen
/dev/sda4          104624      107056    19535040   83  Linux

Bij "/dev/sdb" en "/dev/sdc" (de andere twee fysieke componenten van de "data" vg) neemt de LVM partitie de hele schijf in, maar dat zou niks mogen uitmaken.

De enige manier om uit deze lock-up te geraken is een halt en harde kernel reboot. Als ik daarna opstart "lijkt" de partitie vergroot:

code:

[tim@galactica Desktop]$ sudo lvdisplay /dev/data/video 
  --- Logical volume ---
  LV Name                /dev/data/video
  VG Name                data
  LV UUID                RJamdk-p2ui-xz9a-lbLr-ly1V-YCXP-FF1LCz
  LV Write Access        read/write
  LV Status              suspended
  # open                 0
  LV Size                1,71 TiB
  Current LE             448000
  Segments               4
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:0

Maar de partitie is suspended en ik kan ze niet online krijgen. Mounten lukt natuurlijk niet omdat "/dev/data/video" niet blijkt te bestaan als de partitie suspended is. De rest van de VG functioneert wel.

Om mijn partitie opnieuw werkbaar te maken, moet ik de resize gewoon terugdraaien:

code:

[tim@galactica Desktop]$ sudo lvresize --debug -L -250GB /dev/data/video 
  WARNING: Reducing active logical volume to 1,46 TiB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce video? [y/n]: y
  Reducing logical volume video to 1,46 TiB
  Logical volume video successfully resized

Waarna het volume weer online is en ik opnieuw kan mounten.


Iemand een idee wat er hier aan de hand is? Ik heb deze cyclus nu al twee keer doorlopen, telkens zonder dataverlies, maar toch ben ik een beetje terughoudend qua spelen met mijn partities Vandaar deze post, ik zou niet graag mijn data verliezen bij het zoeken naar een oplossing. Thanks!

[Verwijderd]

probeer eens:

lvresize --debug -L +250G /dev/data/video

[maleadt]

Denk niet dat dat iets zou uitmaken:

code:

[tim@galactica Desktop]$ sudo lvresize --test --debug -L +250G /dev/data/video 
  Test mode: Metadata will NOT be updated.
  Extending logical volume video to 1,71 TiB
  Logical volume video successfully resized
[tim@galactica Desktop]$ sudo lvresize --test --debug -L +250GB /dev/data/video 
  Test mode: Metadata will NOT be updated.
  Extending logical volume video to 1,71 TiB
  Logical volume video successfully resized

In beide gevallen parset lvresize het ingegeven getal correct.
EDIT: nu geen tijd meer, zal het morgen eens zonder --test proberen.

[ Voor 6% gewijzigd door maleadt op 07-02-2010 22:42 ]

[_eXistenZ_]

Afaijk zijn de getallen in LVM2 in blocks, waarschijnlijk 4K blocks, maar dit kun je zien door even partitiegrootte in bytes / aantal blocks in je fdisk, dan kom je wss rond de 4000 uit --> 4K blocks.

[ Voor 3% gewijzigd door _eXistenZ_ op 07-02-2010 22:44 ]

[swbr]

Wat gebeurt er als je lvextend gebruikt in plaats van lvresize?

[maleadt]

Antaresje schreef op zondag 07 februari 2010 @ 22:47:
Wat gebeurt er als je lvextend gebruikt in plaats van lvresize?

Niet veel, vermoed ik:

code:

[tim@galactica Desktop]$ md5sum $(which lvresize)
8019982dd7c1a96dbf7946063ddedb83  /sbin/lvresize
[tim@galactica Desktop]$ md5sum $(which lvextend)
8019982dd7c1a96dbf7946063ddedb83  /sbin/lvextend

lvresize.c leert me dat het verschil ligt in de mate waarin lvm gaat klagen (lvextend klaagt bij verkleinen of minteken, lvrecude bij vergroten of plusteken, lvresize laat alles toe), maar essentieel is de functionaliteit identiek.

[ Voor 4% gewijzigd door maleadt op 07-02-2010 22:54 ]

[swbr]

Misschien, en dit verzin ik hier ter plekke, snapt lvm niet dat hij die 250GB van twee disken moet pakken. Je zou kunnen proberen om 'lvresize -L +170GB /dev/sda1' te doen, en als dat werkt dezelfde truuk nog een keer voor je andere disk uithalen.

Iets anders waar ik wel eens tegen aan ben gelopen was dat lvm een eindig aantal PE's per lv kon hebben, maar dan hebben we het over de tijd van HPUX 10.2, ik mag hopen je dat daar tegenwoordig niet zo snel meer tegen aan loopt

[maleadt]

Nope, LVM snapt wel degelijk dat hij beide disks moet gebruiken, en dat blijkt ook het probleem niet te veroorzaken. Aangezien ik dacht dat LVM er misschien niet goed in slaagde de partitie uit te breiden over twee fysieke partities, heb ik eens een resize gedaan die zich beperkt tot de vrije ruimte op sda1. Maar helaas:

code:

[tim@galactica Desktop]$ sudo umount /media/Video/
[tim@galactica Desktop]$ sudo lvresize --debug -L +175GB /dev/data/video
  Extending logical volume video to 1,64 TiB
  device-mapper: resume ioctl failed: Ongeldig argument
  Unable to resume data-video (254:0)
  Problem reactivating video
[tim@galactica Desktop]$ dmesg | tail
device-mapper: table: 254:0: sda1 too small for target: start=1578606976, len=367001600, dev_size=1677844481

[Rainmaker]

Ik meen me te herinneren dat er een maximum zat aan het aantal LE's wat aan 1 LV kan worden toegekend. Een snelle google tocht zegt me echter weinig over LVM's limitations.

Het is LVM2 neem ik aan? (lvm version)

Lukt het je wel om video met bijvoorbeeld 1 PE te vergroten? Lukt het je om andere LV's te vergroten binnen de VG?

Ik denk namelijk dat er best wel eens een limiet bij 384000 kan liggen (de huidige grootte).

Enige oplossing daarvoor is ben ik bang je PE size aanpassen. Probeer eens

code:

vgchange -s 32M data

en dan je LV te vergroten.

Waarschuwing; ik heb dit nog nooit gedaan, geen idee of dit zonder dataverlies gaat. Volgens de man page wel.

[ Voor 4% gewijzigd door Rainmaker op 23-02-2010 16:28 ]

[maleadt]

Ik gebruik LVM2, waarvan ik volgende limieten gevonden heb:

code:

#LV: geen limiet (al rapporteert system-lvm-config 256?)
#PV: geen limiet (al rapporteert system-lvm-config 256?)
#PE: geen limiet

De PE size aanpassen zal dus niet veel uitmaken, zie ook hieronder.

Ik heb ook een nieuw volume proberen aanmaken, wat ook faalde toen ik de volledige grootte probeerde (verspreid over beide volumes dus). Dit zegt me dat het niet de PE limiet van het LV 'video' is dat roet in het eten gooit.
Wanneer ik echter een test volume van 1 PE aanmaakte, was dit geen probleem. 10000 PE's toewijzen lukte ook, maar 20000 lukte dan weer niet, wat wel nog ruim binnen de grenzen van het aantal vrije PE's op /dev/sda valt (en dus niet over de PV grens gaat). Zo lukte het mij ook om het LV 'video' met 10000 PE's te vergroten, maar meer zal mij opnieuw fouten opleveren.

Vreemd probleem...