/dev/md1 ist voll

[Freakster]

Hallo Debianforum-Community,

ich habe einen Server, auf dem Plesk Onyx installiert ist. Heute erhielt ich die Info, dass Plesk sich nicht aktualisieren kann, da der Speicherplatz nicht ausreicht.
Nach einiger Recherche ist mir aufgefallen, dass /dev/md1 zu 99% voll ist:

Code: Alles auswählen

Filesystem             Size  Used Avail Use% Mounted on
udev                   7.8G     0  7.8G   0% /dev
tmpfs                  1.6G   17M  1.6G   2% /run
/dev/md1               3.9G  3.9G   43M  99% /
/dev/vg00/usr          4.8G  4.0G  628M  87% /usr
tmpfs                  7.9G  276K  7.9G   1% /dev/shm
tmpfs                  5.0M   20K  5.0M   1% /run/lock
tmpfs                  7.9G     0  7.9G   0% /sys/fs/cgroup
none                   7.9G   60K  7.9G   1% /tmp
/dev/mapper/vg00-home  9.8G   15M  9.3G   1% /home
/dev/mapper/vg00-var    54G   29G   24G  55% /var
tmpfs                  1.6G     0  1.6G   0% /run/user/1000

Leider gelingt es mir nicht, hier zu vergrößern oä. obwohl 1,7TB zur Verfügung stehen. Ich habe bereits unter /dev/vg00/user und /home mit:

Code: Alles auswählen

lvextend -L +5GB /dev/vg00/user

die entsprechenden Verzeichnisse angepasst, jedoch ist dies nicht zielführend.
Hat jemand eine Idee was ich tun könnte. Ich vermute, dass das Problem hier beim RAID liegt, daher gern auch Tipps falls ich in die falsche Richtung denke oder ggf. eine Fehlkonfiguration von Plesk vorliegen könnte.

Vielen Dank!

[debilian]

Als Erstes mal schaun, was gelöscht werden kann, damit das System wieder aus den belegten 99% raus kommt?!

[MSfree]

Du hast /usr, /home und /var auf eigenen Partitionen. Eigentlich sollte bei so einer Einteilung fast nichts auf der root-Partition vorhanden sein. Was gibt

Code: Alles auswählen

su -
du --max-depth=1 /

aus?

[Freakster]

Du hast /usr, /home und /var auf eigenen Partitionen. Eigentlich sollte bei so einer Einteilung fast nichts auf der root-Partition vorhanden sein. Was gibt

Code: Alles auswählen

su -
du --max-depth=1 /

aus?

Code: Alles auswählen

root@control:~# du --max-depth=1 /
13064   /sbin
4098520 /usr
48      /lost+found
29809928        /var
2021912 /opt
276     /dev
599112  /lib
4       /srv
1294696 /root
14356   /home
8       /media
4       /lib64
10580   /bin
0       /sys
4       /mnt
du: cannot access '/proc/13984/task/13984/fd/4': No such file or directory
du: cannot access '/proc/13984/task/13984/fdinfo/4': No such file or directory
du: cannot access '/proc/13984/fd/3': No such file or directory
du: cannot access '/proc/13984/fdinfo/3': No such file or directory
0       /proc
13740   /etc
17108   /run
64      /tmp
87708   /boot
37981140        /

[MSfree]

Code: Alles auswählen

root@control:~# du --max-depth=1 /
2021912 /opt
599112  /lib
1294696 /root

Das sind die Verzeichnisse, die du dir mal genauer anschauen solltest.
Warum hat das /root-Verzeichnis 1.3GB belegt? Das ist das Home-Verzeichnis von root, in dem nur ein paar Hundert kByte stecken sollten. Sind da Downloads von Programmpaketen versteckt, die dort nichts zu suchen haben?

[cosinus]

Das unkomplizierte Vergrößern kann hier schwierig bis unmöglich sein. Dein rootfs liegt auf einem RAID, die anderen sind logical volumes.
Wie sieht deine Platten-/Partitionskonfig aus?

[Freakster]

Das sind die Verzeichnisse, die du dir mal genauer anschauen solltest.
Warum hat das /root-Verzeichnis 1.3GB belegt? Das ist das Home-Verzeichnis von root, in dem nur ein paar Hundert kByte stecken sollten. Sind da Downloads von Programmpaketen versteckt, die dort nichts zu suchen haben?

Ich habe mal mit ncdu reingeschaut, allein 616MB werden von /.cache/Cypress belegt. Weitere 278MB von /.npm/cacache

[Freakster]

Das unkomplizierte Vergrößern kann hier schwierig bis unmöglich sein. Dein rootfs liegt auf einem RAID, die anderen sind logical volumes.
Wie sieht deine Platten-/Partitionskonfig aus?

Ich habe den Server bereits Vorpartitioniert erhalten, daher habe ich in diesem Bereich keine wirkliche Erfahrung. (Man lernt ja nie aus)
Wenn du mir sagst was ich wo suchen soll, kann ich dir deine Frage sicher beantworten!

Vielen Dank

[debilian]

Kopier doch erstmal die unnötigen (cache) Inhalte von /root/ auf einen temporären Platz auf eine Partition,
die noch Platz hat - dann lösch diese unter /root/

danach bist du wieder flexibler...

[cosinus]

Ich habe den Server bereits Vorpartitioniert erhalten, daher habe ich in diesem Bereich keine wirkliche Erfahrung. (Man lernt ja nie aus)
Wenn du mir sagst was ich wo suchen soll, kann ich dir deine Frage sicher beantworten!

Klar. Poste mal die Ausgaben von diesen Befehlen (als root ausführen):

Code: Alles auswählen

pvs
vgs
lvs
lsblk -f

[Freakster]

Code: Alles auswählen

root@control:/# pvs
  PV         VG   Fmt  Attr PSize PFree 
  /dev/md3   vg00 lvm2 a--  1.81t <1.67t

Code: Alles auswählen

root@control:/# vgs
  VG   #PV #LV #SN Attr   VSize VFree 
  vg00   1   3   0 wz--n- 1.81t <1.67t

Code: Alles auswählen

root@control:/# lvs
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home vg00 -wi-ao---- 50.00g                                                    
  usr  vg00 -wi-ao---- 35.00g                                                    
  var  vg00 -wi-ao---- 65.00g    

Code: Alles auswählen

root@control:/# lsblk -f
NAME            FSTYPE            LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                           
├─sda1          linux_raid_member       600b0138-2664-b50f-1f51-fb8978ee93fe                  
│ └─md1         ext3              root  7e0d5d1a-9279-42a4-8aa5-06cfd81260d5     41.9M    99% /
├─sda2          swap                    30601833-0a9a-4d8b-b18a-60f9c54e2d83                  [SWAP]
└─sda3          linux_raid_member       424915b8-97f3-87a9-1f51-fb8978ee93fe                  
  └─md3         LVM2_member             cKlbFL-s85l-MoxF-oPLD-UjoM-O6T0-rtZ0ze                
    ├─vg00-usr  ext4              usr   b501fa4c-b20e-4073-bac8-ec835ab8772c     28.9G    11% /usr
    ├─vg00-var  ext4              var   bb6faa40-e9d2-432d-b866-02f61c739679     24.3G    51% /var
    └─vg00-home ext4              home  5a95b953-af10-4593-9175-ea7e75a1440b       47G     0% /home
sdb                                                                                           
├─sdb1          linux_raid_member       600b0138-2664-b50f-1f51-fb8978ee93fe                  
│ └─md1         ext3              root  7e0d5d1a-9279-42a4-8aa5-06cfd81260d5     41.9M    99% /
├─sdb2          swap                    e9bad98c-b0db-40a7-8796-8a4992fac8f3                  [SWAP]
└─sdb3          linux_raid_member       424915b8-97f3-87a9-1f51-fb8978ee93fe                  
  └─md3         LVM2_member             cKlbFL-s85l-MoxF-oPLD-UjoM-O6T0-rtZ0ze                
    ├─vg00-usr  ext4              usr   b501fa4c-b20e-4073-bac8-ec835ab8772c     28.9G    11% /usr
    ├─vg00-var  ext4              var   bb6faa40-e9d2-432d-b866-02f61c739679     24.3G    51% /var
    └─vg00-home ext4              home  5a95b953-af10-4593-9175-ea7e75a1440b       47G     0% /home

[MSfree]

Ich habe mal mit ncdu reingeschaut, allein 616MB werden von /.cache/Cypress belegt. Weitere 278MB von /.npm/cacache

Bei Caches wäre ich mutig genug, die einfach zu löschen. Wie der Name schon sagt, ist das Cache, also nur Daten, um Zugriffe zu optimieren. Ist der Cache weg, dauern gewisse Dinge halt ein wenig länger, die Funktion darf ein fehlender Cache nicht beeinträchtigen.

Und weil wir es neulich erst hatten:
Du kannst die jüngste Datei in einem Dateibaum ermitteln, indem du z.B.

Code: Alles auswählen

find /root/.cache/Cypress -type f -printf '%T+ %p\n' | sort | tail -n 1

aufrufst. Sollte sich herausstellen, daß das Zeug da schon jahrelang vor sich hinschimmelt, dann gibt es erstrecht keinen Grund, den alten Cache aufzuheben.

[cosinus]

Code: Alles auswählen

/dev/md3   vg00 lvm2 a--  1.81t <1.67t

/dev/md1               3.9G  3.9G   43M  99% /

omg, da ist ein Array aus 2-TB-Platten und dann wird beim rootfs so herumgeknausert
Interessant ist auch, dass das rootfs als raid device genutzt wird also /dev/md1 während die anderen Dateisysteme wie home, var und usr in logical volumes auf einem anderen raid device liegen ...und root hat "nur" das alte ext3 und kein ext4.

home, usr und var kannst du problemlos vergrößern, weil das logical volumes sind und in der volume group auch noch mehr als genug frei ist (ca. 1.6 TiB)
Aber root wird ein Problem. Weil das eben kein logical volumes ist, da müsste man die Partition und anschließend das Dateisystem vergrößern, aber das wird schwierig weil wohl direkt hinter der Rootpartition kein Platz mehr ist und sofort der Bereich für swap anfängt.

Poste auch ,al die Ausgabe von

Code: Alles auswählen

gdisk -l /dev/sda

[MSfree]

Aber root wird ein Problem. Weil das eben kein logical volumes ist, da müsste man die Partition und anschließend das Dateisystem vergrößern,

Man könnte in dem logical Volume noch eine weitere Partition anlegen, auf die man den Inhalt von /opt verschiebt. Anschließend mountet man diese Partiton als /opt. Das halbiert den Speicherbedarf der root-Partition.

[cosinus]

Anschließend mountet man diese Partiton als /opt. Das halbiert den Speicherbedarf der root-Partition.

/root könnte man auch auslagern in ein neues LV
Und/oder die swap Partitionen löschen und das zur root Partition packen.



BTW: ist

Code: Alles auswählen

du -hd1 /

nicht etwas schöner als

Code: Alles auswählen

du --max-depth=1 /

[Freakster]

Code: Alles auswählen

/dev/md3   vg00 lvm2 a--  1.81t <1.67t

/dev/md1               3.9G  3.9G   43M  99% /

omg, da ist ein Array aus 2-TB-Platten und dann wird beim rootfs so herumgeknausert
Interessant ist auch, dass das rootfs als raid device genutzt wird also /dev/md1 während die anderen Dateisysteme wie home, var und usr in logical volumes auf einem anderen raid device liegen ...und root hat "nur" das alte ext3 und kein ext4.

home, usr und var kannst du problemlos vergrößern, weil das logical volumes sind und in der volume group auch noch mehr als genug frei ist (ca. 1.6 TiB)
Aber root wird ein Problem. Weil das eben kein logical volumes ist, da müsste man die Partition und anschließend das Dateisystem vergrößern, aber das wird schwierig weil wohl direkt hinter der Rootpartition kein Platz mehr ist und sofort der Bereich für swap anfängt.

Poste auch ,al die Ausgabe von

Code: Alles auswählen

gdisk -l /dev/sda

Das bringt mir folgenden Fehler / Aufforderung:

Code: Alles auswählen

root@control:/home/syswolf# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 

[Freakster]

Aber root wird ein Problem. Weil das eben kein logical volumes ist, da müsste man die Partition und anschließend das Dateisystem vergrößern,

Man könnte in dem logical Volume noch eine weitere Partition anlegen, auf die man den Inhalt von /opt verschiebt. Anschließend mountet man diese Partiton als /opt. Das halbiert den Speicherbedarf der root-Partition.

Damit bin ich aktuell dennoch etwas überfragt. Ich habe mich schon recht gut in Debian eingefunden, wenn es um die Basics für Plesk, Apache usw. geht, bei Partitionen und co. habe ich hier definitiv Bildungslücken
Ich werde mich mal etwas umschauen um das Fehlende Wissen aufzufrischen

[cosinus]

Deine Platte ist mit MBR eingerichtet, nicht mit GPT. Mach daher bitte nochmal:

Code: Alles auswählen

fdisk -l /dev/sda

[cosinus]

Nachtrag:
Mit Auslagern meinen @MSfree und ich, dass du zB den Inhalt des Verzeichnisses /opt, das ja gegenwärtig noch auf der Rootpartition liegt, auf ein neues logical volume (LV) verschiebst und dieses neue LV dann nach /opt mountest. Somit wird die Rootpartition nicht mehr von /opt belastet.

Vorgehensweise wäre ungefähr so:

• neues LV erstellen, mit ext4 formatieren und zB nach /mnt mounten
• Inhalt von /opt nach /mnt verschieben
• wenn alles erfolgreich/richtig verschoben wurde: /mnt umounten und fortan als /opt mounten
• Eintrag in der fstab dafür nicht vergessen

Ich weiß aber nicht was du alles in /opt hast also ob du das so im laufenden Betrieb machen kannst.

[MSfree]

Ich weiß aber nicht was du alles in /opt hast also ob du das so im laufenden Betrieb machen kannst.

Das sollte auch im laufenden Betrieb gehen. Linux ist so schlau, Dateien, die im Zugriff sind, erst dann aus dem Verzeichnis zu löschen, wenn der letzte Dateihandle geschlossen ist. Beim Löschen (was auch beim Verschieben passiert) wird bei offenen Dateien nur der Verzeichniseintrag gelöscht, der Platz auf der Platte bleibt aber reserviert und kann vom zugreifenden Programm weiterhin genutzt werden.

Allerdings ist nach der Orgie, die du in deinen 4 Punkten aufführst, ein reboot fällig, damit die Programme, die von /opt laufen, zukünftig auf die Dateien unter ihrem neuen Speicherort zugreifen.

Besser wäre es aber dennoch, die Programme, die auf /opt zugreifen, zu ermitteln und zu beenden, bevor man die Orgie startet. Ein Mittel, um Zugriff auf /opt zu ermitteln, wäre z.B.

Code: Alles auswählen

lsof | grep /opt

[cosinus]

Orgie?! Wie obszön