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

Re: resize2fs in Crypted LVM



Heiko Schlittermann wrote:
> Ulrich Fürst <Fuerst.Ulrich@web.de> (Mi 09 Jan 2013 23:21:14 CET):
> > > Ich denke, Du versuchst, das falsche LV zu resizen.
> > > Und wo ist eigentlich das Crypto-Device, von dem Du im Subject
> > > sprichst?
> > 
> > Das gesamte LV ist crypted, was eigentlich in dem Zusammenhang egal
            -----^----- 
 Mifft. Das muss VG heißen. 

> Wenn das LV gecrypted ist, dann willst Du etwa folgende Schritte
> machen
> 
>     - lvresize
>     - cryptsetup resize
>     - resize2fs

zum "cryptsetup resize": 
ist unter "blockdevice" auch ein LV gemeint? 
Ich habe hier (und muss mich somit korrigieren)

Primäre Partition: /boot 
Logische Partition: crypted VG 
   darin 6 LV (root, swap, tmp, var, usr, home)

So wie ich das sehe "wissen" die LV doch gar nichts vom crypt, oder?
"cryptsetup resize $DEVICE" gibt zumindest nur error code 19 zurück (No
such device).  

Nachdem mich aber irritiert hat, das df und kdf unterschiedliche Werte
ausgeben habe ich mich mal näher damit beschäftigt. 

$ df -h
/dev/mapper/laptop-tmp   651M   11M  607M   2% /tmp
/dev/mapper/laptop-home  275G  155G  106G  60% /home

/tmp ist größer als vorher und /home kleiner. 

$ df --si
/dev/mapper/laptop-tmp   683M   12M  637M   2% /tmp
/dev/mapper/laptop-home  295G  167G  114G  60% /home

so bekomme ich die gleichen Werte wie kdf und /tmp ist auch hier größer
geworden. Aber /home nicht kleiner und beides unterscheidet sich von
lvdisplay. 

Ich hatte aber (wenn ich schon mal dabei bin) Platz schaffen wollen: 
# resize2fs -p /dev/mapper/laptop-home 275G
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/laptop-home to 72089600 (4k)
blocks.
Begin pass 2 (max = 404065)^M
Relocating blocks
HXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 2240)
Scanning inode table
HXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/mapper/laptop-home is now 72089600 blocks long.



Macht für mich nach Adam-Riese 275 GB



# lvreduce --size 280g /dev/mapper/laptop-home
  WARNING: Reducing active logical volume to 279.00 GiB^M
  THIS MAY DESTROY YOUR DATA (filesystem etc.)^M
Do you really want to reduce home? [y/n]: y^M
  Reducing logical volume home to 279.00 GiB^M
  Logical volume home successfully resized^M



Und das Dateisystem wieder vergrößern auf Maximum



# resize2fs /dev/mapper/laptop-home
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/laptop-home to 73138176 (4k) blocks.
The filesystem on /dev/mapper/laptop-home is now 73138176 blocks long.



Also sollte das Dateisystem jetzt auch wieder 279 GB haben. Das
allerdings zeigt weder df noch kdf an. Passt das jetzt oder ist da was
schief gelaufen. 

Ach ja. 
lvdisplay sagt für /home 279 GB
vgdisplay sagt das ich jetzt im VG 1 GB frei habe. 

Da tut sich mir die Frage auf (weil ich ja mit 15 GB freiem Platz
gerechnet habe): 
Welche Anzeige hat den nun recht? Im Zweifel wohl lvdisplay und
vgdisplay!? Weil für den Fall, dass ich nochmal reduzieren muss, würde
ich vorher schon gerne verlässlich wissen wohin ich reduzieren muss,
damit ich auch wirklich sinnvolle Mengen frei bekomme. 

Falls lvdisplay die richtigen Werte anzeigt (davon gehe ich mal
aus) kann ich es mir wohl sparen noch ein
# lvextend -r --size 279G /dev/mapper/laptop-home

hinterher zu schicken um sicher zu gehen, dass auf /home LV-Größe und
Filesystem-Größe gleich sind?

Vielen Dank schon mal fürs helfen

Ulrich

P.S. Der einzeln stehen Post von mir liegt daran, dass List-Reply aus
dem Sent-Ordner offensichtlich nicht funktioniert, bzw. Referenzen
entfernt/nicht mitnimmt. Sorry. 


-- Zufallssignatur -- 
Findet eine dressierte Rate auf ihrem Weg fünfmal keinen Käse,
nimmt sie einen anderen Weg.
Ein Mensch kann zwanzig Jahre und mehr auf Käse warten.


Reply to: