06.02.2019

24399

Ubuntu-vg-ubuntu-lv ist voll

Hallöchen miteinander

Ich habe das Problem, dass auf 2 Ubuntu Servern ein Filesystem namens "/dev/mapper/ubuntu--vg--ubuntu--lv" voll läuft und ich nicht weiss, was folgendes Filesystem macht, oder wie ich es bereinigen kann.

Hat jemand von euch hiermit irgendwelche Erfahrungen?

Besten Dank im Voraus für die Antworten.
LG fiffi1

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 400615

Url: https://administrator.de/contentid/400615

Ausgedruckt am: 22.11.2024 um 16:11 Uhr

24 Kommentare

Neuester Kommentar

Hallo,

das ist ein Logical Volume. Siehe auch:
https:// en.wikipedia.org/wiki/Logical_Volume_Manager

Hier eine Anleitung wie man das erweitern kann:
https://www.thomas-krenn.com/en/wiki/Increasing_a_Logical_Volume

VG
Exception

Moin,

das ist ein LV, daß man auch recht einfach werweitern kann., wie exception ja schon geschrieben hat.

Auf welches verzeichnis ist es denn gemountet?

/
/home
/var
/srv
oder ein andeers?

oder ein anderes? mit du läßt sich herausfinden, welche untervezeichnisse voll sind und entsprechende Maßnahmen ergreifen.

Oft ist es /var mit Logmeldungen oder /home oder /srv, weil zuviel draufgeschrieben wurde.

lks

Hallo Lochkartenstanzer

So wie ich das auffasse ist es in / gemountet, habe dir aber noch ein Bild, evtl kannst du mehr damit anfangen als ich.

Zitat von @fiffi1:

Hallo Lochkartenstanzer

So wie ich das auffasse ist es in / gemountet, habe dir aber noch ein Bild, evtl kannst du mehr damit anfangen als ich.

ja. Ist als Root-fs gemountet. Ist aber deutlich zu klein dimesioniert mit nur 4GB. Entweder feheln die ganzen anderen Filesysteme, die dann als /var, /usr, /srv/ home/, etc. gemountet werden (dann reichen wenige hundert MB für root) oder jemand hat da richtig Bockmist gemacht.

Mach mal einen "cat /proc/mounts" und vergleiche das mit "/etc/fstab".

Am besten jemanden holen, der sich damit auskennt, bevor Ihr da mehr kaputtmacht, gerne auch einen hier aus dem Forum, wenn Du den Leuten vertraust.

lks

Ich habe da noch folgende filesystems

Zitat von @fiffi1:

Ich habe da noch folgende filesystems

offensichtlich sind für die großen verzeichnisse (/var, /srv oder /home) keine extra filesysteme vorgesehen. Schau mal in /etc/fstab.

lks

in fstab sind mir 3 UUID eingetragen mehr leider nicht..

Zitat von @fiffi1:

in fstab sind mir 3 UUID eingetragen mehr leider nicht..

Für welchen Mountpoint außer / und /boot denn?

Aber eigentlich ist es egal ob /home /srv/ oder /var,. jedenfall ssind 4GB deutlich zu klein für so eine Konfiguration. Hau dem "Installateur" auf die Finger oder tritt ihm in den Gluteus Maximus.

lks

es ist noch /media

werde ich mahcen

heisst dies dass ich diese 3.9GB gar nicht kleiner bringe?

Zitat von @fiffi1:

es ist noch /media

werde ich mahcen

heisst dies dass ich diese 3.9GB gar nicht kleiner bringe?

Doch, aber nicht viel, wenn der Serevr was sinnvolles machen soll. eine Minimal-Installation von Ubuntu-Sererv hat ca. 500MB.

Mach mal ein du -shc /, damit man sieht, "wohin der Platz geht".

lks

PS: Wie groß sind den die Platten in den Kisten?

Hallo

Finde es nicht gut wenn ihr hier so schnell mit halbwissen gegen Installateure schießt.
Das ist offensichtlich eine owncloud_instanz. Die Daten liegen in /media/owncloud data.

Das ist soweit erstmal ein völlig legitimes Setup.

Ohne zu sehen was genau den speicher auf / aufzehrt kann man nicht helfen.

Grüße
bloody

Zitat von @bloodstix:

Finde es nicht gut wenn ihr hier so schnell mit halbwissen gegen Installateure schießt.
Das ist offensichtlich eine owncloud_instanz. Die Daten liegen in /media/owncloud data.

Woher weißt Du das denn? hast Du das etwas verbrochen? Zumindest gab es auf Nachfragen keine Hinweise drauf, wo die Daten liegen und auf welchen Mountpoint die gehängt werden. Und wenn so etwas passiert, ist es eine Fehlplanung des Installateurs. Und 4GB ist eindeutig zu klein, wenn nicht mindestens var auf einem eigenen Filesystem liegt.

Das ist soweit erstmal ein völlig legitimes Setup.

... das aber Probleme macht, weil das root-filesystem entweder zu klein dimensioniert wurde oder keine notwendigen Filesysteme dazu gemountet wurden.

Ohne zu sehen was genau den speicher auf / aufzehrt kann man nicht helfen.

Deswegen der Hinweis, mit du nachzuschauen.

lks

Ich hab das nich installiert nein, aber so eine Partitionierung hab ich schon öfter angetroffen. Wenn das system und log rotate usw richtig konfiguriert ist reichen 4gb rootfs auch ohne separate var-partition für einen simplen owncloud-Server mehr als aus.

Und die Info das des ein oc Server ist hab ich dem fast vollständigen 2. Screen von den mounts entnommen.

Nichts desto trotz: irgendwas liegt auf / was dort nicht hingehört oder ein log ist langsam zu gross und würde noch nie rotiert.

Habe den Befehl ausgeführt, es kamm immer die Meldung: du: cannot access `/pfad

6.8G Total

Die Systemplatte ist 4GB und die Datenplatte 5.5 GB
Das System läuft Virtuell.

Zitat von @fiffi1:

Habe den Befehl ausgeführt, es kamm immer die Meldung: du: cannot access `/pfad

im /proc-verzeichnis ist das normal.

6.8G Total
Die Systemplatte ist 4GB und die Datenplatte 5.5 GB

Die "Datenplatte" ist aber auch etwas knapp bemessen.

Welche Aufgaben haben denn die Server?

Und schreibe mal die Ergebnisse von

du -shcx  /*

und

cat /proc/mounts

hier rein.

Du mußt nicht immer einen screenshot machen, ein copy&paste geht auch.

*LOL*

Was geht denn hier ab? Man sieht doch in dem Screenshot vom Thread-Eröffner das die "Daten"-Platte "/dev/sdb1" ist und 295GB groß ist mit 304MB belegt. Und nicht 5.5GB. Der Fragende versteht offenbar nicht was gemeint ist und ein Fachmann nimmt es so hin und redet ihm nach ... Ich klink mich hier aus, das macht so kein Sinn.

Zitat von @bloodstix:

*LOL*

Was geht denn hier ab? Man sieht doch in dem Screenshot vom Thread-Eröffner das die "Daten"-Platte "/dev/sdb1" ist und 295GB groß ist mit 304MB belegt. Und nicht 5.5GB. Der Fragende versteht offenbar nicht was gemeint ist und ein Fachmann nimmt es so hin und redet ihm nach ... Ich klink mich hier aus, das macht so kein Sinn.

Nunja, nicht jeder schaut sich die Screenshots so genau an wie Du.

Aber die Datenplatte ist in diesem Fall ja unwichtig. Es geht darum festzustellen, wo die 4GB für das root-fs hingehen. Und solange der TO nicht liefert, kann man nur herumraten.

lks

du -shcx /*
990M /var
0 /vmlinuz
0 /vmlinuz.old
3.0G total
recon@swwbnc:~$ sudo du -shcx /*
[sudo] password for recon:
15M /bin
152M /boot
0 /dev
5.5M /etc
48K /home
0 /initrd.img
0 /initrd.img.old
1.0G /lib
4.0K /lib64
16K /lost+found
4.0K /media
4.0K /mnt
4.0K /opt
du: cannot access '/proc/42926': No such file or directory
du: cannot access '/proc/42927/task/42927/fd/4': No such file or directory
du: cannot access '/proc/42927/task/42927/fdinfo/4': No such file or directory
du: cannot access '/proc/42927/fd/3': No such file or directory
du: cannot access '/proc/42927/fdinfo/3': No such file or directory
0 /proc
60K /root
948K /run
16M /sbin
20K /snap
4.0K /srv
0 /sys
272K /tmp
854M /usr
1.8G /var
0 /vmlinuz
0 /vmlinuz.old
3.8G total

cat /proc/mounts

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=1983444k,nr_inodes=495861,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=402816k,mode=755 0 0
/dev/mapper/ubuntu--vg-ubuntu--lv / ext4 rw,relatime,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17831 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/loop0 /snap/nextcloud/10314 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core/6130 squashfs ro,nodev,relatime 0 0
/dev/loop3 /snap/nextcloud/10791 squashfs ro,nodev,relatime 0 0
/dev/loop5 /snap/core/6350 squashfs ro,nodev,relatime 0 0
/dev/loop2 /snap/core/6259 squashfs ro,nodev,relatime 0 0
/dev/loop6 /snap/nextcloud/11130 squashfs ro,nodev,relatime 0 0
/dev/sdb1 /media/Nextcloud_data ext4 rw,relatime,data=ordered 0 0
/dev/sda2 /boot ext4 rw,relatime,data=ordered 0 0
lxcfs /var/lib/lxcfs fuse.lxcfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
tmpfs /run/snapd/ns tmpfs rw,nosuid,noexec,relatime,size=402816k,mode=755 0 0
nsfs /run/snapd/ns/nextcloud.mnt nsfs rw 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=402812k,mode=700,uid=1000,gid=1000 0 0

Habe nochmals nachgeschaut. Im Hyper-V wurden 2 Disks Deffiniert, die erste 105 GB und die zweite 2TB.
Die Platten wurden Dynamisch konfiguriert. Kann es sein, das Ubuntu nicht mit dem klar kommt?

Moin,

Pack die Ausgabe mal zwischen Code-Tags, damit man sie lesen kann.

Dein /var ist voll. Da laufen entweder logdateien oder der Cache Amok.

Da solltest Du mal genauer reinschauen.

lks

Zitat von @fiffi1:

Habe nochmals nachgeschaut. Im Hyper-V wurden 2 Disks Deffiniert, die erste 105 GB und die zweite 2TB.
Die Platten wurden Dynamisch konfiguriert. Kann es sein, das Ubuntu nicht mit dem klar kommt?

Damut hat Ubuntu überhaupt kein Problem.

Was mich verwundert, daß Du nur eine 4GB-Psrtition virgesehen gast, ibwohl genug Platz ist.

lks

Hallo,

bitte Ausgaben zukünftig in Code Tags setzen. Das macht das ganze deutlich übersichtlicher.

Die Platten wurden Dynamisch konfiguriert. Kann es sein, das Ubuntu nicht mit dem klar kommt?

Hat nichts damit zu tun. Das betrifft nur Hyper-V, wie er die Disk anlegt. Das Gastsystem sieht die volle Kapazität der Disk.

. Im Hyper-V wurden 2 Disks Deffiniert, die erste 105 GB und die zweite 2TB.

Ok. Und warum nutzt du diese Kapazitäten nicht?
Bitte mal die Ausgabe von lvdisplay und vgdisplay posten. Nicht dass es noch LVs gibt, die aber aktuell nicht gemountet sind oder der restliche Speicherplatz einfach schlicht einer Volume Gruppe zugewiesen wurde....

Bezüglich dem eigentlichen Problem hat @Lochkartenstanzer schon alles geschrieben.

*LOL*
Was geht denn hier ab?

Ruhig Blut @bloodstix. Man darf schon mal was übersehen bzw. auf korrekte Angaben vertrauen....

Pack die Azsgabe mal zwischen Cide-Rags, damit man sie lesen kann.

Was sind "Cide-Rags"?

Habe nun herausgefunden wie ich es machen muss.

Besten Dank für eure Hilfe, ohne euch wäre ich noch in 100 Jahren daran, das Problem zu Lösen.
Konnte das LV nach langem probieren endlich vergrössern.

LG fiffi1