unable do open file /xxxx/xxx/xxx no space left - inode 100% full

[Thhunder]

Hey Leute,
Ich hab mit meinem Proxmox VE 6.1-3 das problem das er mir sagt das kein Festplatten speicher mehr vorhanden ist,
datentechnisch ist dieser bei 33%
Laut inode aber zu 100% Voll
was kann ich hier nun machen um "platz" schaffen zu können um mit dem system wieder normal arbeiten zu können?

Zur Config des servers:

systempartition (/root) hat 15 GB davon sind 33% belegt aber 100% der inode ist voll

Spoiler: df -lh

# df -lh
Filesystem            Size  Used Avail Use% Mounted on
udev                   63G     0   63G   0% /dev
tmpfs                  13G   11M   13G   1% /run
/dev/mapper/vg0-root   15G  4.6G  9.4G  33% /
tmpfs                  63G   43M   63G   1% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                  63G     0   63G   0% /sys/fs/cgroup
/dev/md0              487M  234M  228M  51% /boot
/dev/fuse              30M   20K   30M   1% /etc/pve
tmpfs                  13G     0   13G   0% /run/user/0

Spoiler: df -hi

# df -hi
Filesystem                          Inodes IUsed IFree IUse% Mounted on
udev                                   16M   539   16M    1% /dev
tmpfs                                  16M  3.3K   16M    1% /run
/dev/mapper/vg0-root                  960K  960K     0  100% /
tmpfs                                  16M    99   16M    1% /dev/shm
tmpfs                                  16M    15   16M    1% /run/lock
tmpfs                                  16M    18   16M    1% /sys/fs/cgroup
/dev/md0                              128K   358  128K    1% /boot
/dev/fuse                             9.8K    35  9.8K    1% /etc/pve
//u215690.your-storagebox.de/backup      0     0     0     - /mnt/pve/backup
//u214801.your-backup.de/backup          0     0     0     - /mnt/pve/storage
tmpfs                                  16M    11   16M    1% /run/user/0

die vm daten liegen auf einer eigenen Partition auch die backup daten sind hier nicht auf der root partition gelager oder image files etc. alles ausgelagert.
hat hier jemand eine Lösung oder hilfemöglichkeiten zur Lösungsfindung? ein solches problem hatte ich bisher noch nie gehabt und bin hier sehr ratlos, wenn man überall nach ließt heißt es nur "lösch daten" aber hier gibt es nichts zu löschen, weder irgendwelche logfiles noch sonst etwas vom system kann gelöscht werden um platz zu schaffen. Zumal sobald ich die logfiles gelöscht hatte (doppelte oder bereits alte gzip logfiles etc.) dauert es maximal 5 minuten und hier geht dann wieder nix mehr da reicht meist schon das "apt update"

Zum System:
CPU: Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz (6Core/12Threads)
RAM 128GB
2x2TB HDD im soft-Raid unterteilt auf 16GB fürs rootsystem rest für die VMs
div. externe Storages für iso images und backups
Debian 10.2 Proxmox VE 6.1-3


Lieben Gruß

Frank - Thhunder

 

[oguz]

hi,

was kann ich hier nun machen um "platz" schaffen zu können um mit dem system wieder normal arbeiten zu können?

mit diesem kommando findest du die ordnern, die die meisten files drin haben:

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

wenn du viele kleine files hast, kann es passieren dass du keine inodes mehr hast. finde diese ordnern, und lösche was du kannst.

du kannst auch von /var/cache/apt/archives die alten packages löschen.

 

[Thhunder]

wenn ich irgendwas hätte zum löschen wäre das ja bereits gemacht... hab schon alte logfiles gelöscht alle archive und so nen kram hier mal die ausgabe von dem find befehl:

Spoiler: find

/ # find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
      1 installimage.conf
      1 installimage.debug
      1 post-install
      5 home
     14 root
    855 etc
   4036 var
  69705 usr

Hab da also nichts mehr was ich wirklich rauswerfen könnte und zugriff dritter kann ich hier ausschließen das hab ich bereits ausgiebig durch gesehen da ist nichts drauf

hier auch nochmal ein anderer suchdurchlauf mittels:

for i in /*; do echo $i; find $i |wc -l; done

Spoiler: suchlauf 2

 # for i in /*; do echo $i; find $i |wc -l; done
/bin
1
/boot
349
/dev
628
/etc
1872
/home
10
/installimage.conf
1
/installimage.debug
1
/lib
1
/lib32
1
/lib64
1
/libx32
1
/lost+found
1
/media
3
/mnt
157
/opt
1
/post-install
1
/proc
find: ‘/proc/95665’: No such file or directory
134945
/root
25
/run
5730
/sbin
1
/srv
1
/sys
129595
/tmp
12
/usr
86921
/var
904123

in /var hab ich nix auffälliges abgesehen von dem /var/lib/samba/.... ordner dieser sieht dann so aus:

Spoiler: /var/lib/samba/....

#  for i in /var/lib/samba/*; do echo $i; find $i |wc -l; done
/var/lib/samba/private
889739
[/SPOILER]

den samba dienst nutze ich selbst so gar nicht, und da ist auch nichts erreichbar auf meinem server diesbezüglich das ist das was ich im Detail raus gefischt habe was sehr auffällig ist.
alles andere wäre hier im normalen Rahmen im vergleich zu einer "normalen" linux installation (als normal betrachte ich hier zum vergleich mein desktop system)

in dem samba ordner sind lediglich 0byte dateien drin mit div. Zahlen wie 95430 so sichtlich recht random gewählt aber aufsteigend sobald ich hier auch nur irgendwas an platz schaffe knallt er mir das dort wieder rein und voll und woher das kommt verstehe ich hier nicht.

Lieben Gruß

Frank - Thhunder

 

[oguz]

schaut nach diesem bug aus[0].

es ist eigentlich ein upstream bug[1]

es gibt momentan leider keinen schellen fix... du kannst vielleicht einen cronjob liegen, der jede minute die ordner leert.

wir schauen uns das an, ich schreibe hier nochmal wenn wir mehr wissen

[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=2333
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912717

 

[Thhunder]

ok, sieht in jedem fall danach aus.
die erstellung der 0 byte dateien erfolgt pro sekunde wenn ich das richtig mitverfolgen kann aber es hat auf jeden fall abhilfe geschaffen das löschen dieser 0 byte datein jetzt kann man damit wieder arbeiten auf jeden fall schonmal danke dafür

Lieben Gruß

Frank - Thhunder

 

[Thhunder]

#Push
Gibts hier schon einen status zu der sache evtl. auch eine dauerhafte Lösung durch ein entsprechendes update? Wäre zum Jahresende doch passend

Lieben Gruß

Frank - Thhunder

 

[oguz]

hi,

anything we do will be only a workround. it needs to be fixed upstream (see the debian bug link i've sent)