KVM-vServer "Neptun": 16 statt 80 Gigabyte, WTF?

    Ich migriere noch immer meinen v(olks)Server 1000 auf einen KVM-Server "Neptun".
    Im Angebot ist von "80 GB Speicherplatz" die Rede.


    Nun, so recht klappen wollte der SCP-Vorgang dann aber nicht:


    Code
    # df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/vtbd0p2     16G     15G   -370M   102%    /
devfs           1.0k    1.0k      0B   100%    /dev


    Muss ich das verstehen?

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    Das solltet ihr doch besser wissen. ;)
    Ich habe mich einfach mal auf euer FreeBSD-Image verlassen.


    Nachtrag:


    Code
    # gpart show
=>      34  39062433  vtbd0  GPT  (78G) [CORRUPT]
        34       128      1  freebsd-boot  (64k)
       162  35651456      2  freebsd-ufs  (17G)
  35651618   3410849         - free -  (1.6G)


    Der erste Eintrag macht mir Sorgen.

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    Nun, hier scheint es jedoch keine Absicht zu sein. "CORRUPT" weist eher auf einen Fehler als auf bewusst freien Speicher hin.

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    Problemlösung: In den Single-user-mode booten:


    Code
    # nextboot -o "-s" -k kernel && reboot


    Dort können wir (Achtung, US-Tastatur! Der Bindestrich liegt auf ß, der Schrägstrich auf -) unser Dateisystem nach Belieben ändern:


    Code
    # gpart recover vtbd0
# gpart resize -i 2 vtbd0
# growfs -s 77G /dev/vtbd0p2


    Neu starten (reboot), funktioniert.
    Warum das der Kunde machen muss, wenn er schon ein fertiges FreeBSD-Image bekommt... nun ja.

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    Zitat

    Warum das der Kunde machen muss, wenn er schon ein fertiges FreeBSD-Image bekommt... nun ja.

    Weil es Kunden gibt die z.B. eine eigene Daten-Partition nutzten möchten. Eine Partition nachträglich zu verkleinern, ist gefährlich.


    Ein anderes Thema ist das Reservieren von Speicherplatz für Snapshots.

    Danke für die Tipps. Aber ich möchte trotzdem nochmal kurz nachfragen:

    Zitat von tuxproject.de

    Code
    # gpart recover vtbd0# gpart resize -i 2 vtbd0# growfs -s 77G /dev/vtbd0p2



    Bei dem growfs bekomme ich leider nur: "growfs: requested size 77GB is larger than the available 17GB". Das stimmt auch, denn 'gpart show' meint:


    Code
    ... vtbd0	GPT (78GB)
...    1	freebsd-boot	(64GB)
...    2	freebsd-ufs	(17GB)
...     	- free -	(61GB)


    Hinweise, wie ich den letzten Slice mit seinen 61GB für das growfs des Slice 2 nutzen kann, sind sehr willkommen.

    Verdammt. Gerade wollte ich "RTFM" schreiben...


    Das Dumme ist: Ich weiß nicht mehr, wie ich das damals gelöst hatte. :-/ Ich hatte ein ähnliches Phänomen mittendrin.


    Mein Tipp: Frag mal auf bsdforen.de.

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    Ich wollte auf meinem System nun auch mal schauen, wie es mit der Partitionierung aussieht, vor allem da mir beim Einloggen als root folgendes angezeigt wird:

    Code
    Usage of /:   12.0% of 19.29GB


    Das kommt mir auch ein bisschen komisch vor.


    Leider funktioniert bei mir "gpart show" nicht, sondern es wird nur diese Fehlermeldung ausgegeben:

    Code
    *** Fatal error: open(show): No such file or directory.


    Muss ich noch irgendetwas Zusätzliches installieren?

    Zitat von rolando

    "Device busy"


    Trickreich.

    An dem Punkt war ich mit meinem FreeBSD Server eben auch. Geholfen hat dieser Artikel, welcher im Grunde nur sagt, man solle vor dem gpart resize noch folgendes setzen: sysctl kern.geom.debugflags=16


    D.h., man tut insg. folgendes:


    • In SSH-Session:
      Code
      nextboot -o "-s" -k kernel && reboot
    • Dann auf VServerControlPanel die VNC Console öffnen (oben rechts)
    • Dort wie oben beschrieben folgendes eingeben

      Code
      # gpart recover vtbd0
# sysctl kern.geom.debugflags=16
# gpart resize -i 2 vtbd0
# growfs -s 77G /dev/vtbd0p2