Die Platte ist voll und ich kann nichts mehr löschen

  • Hallo,


    es geht hier zwar um SD-Karten aber sie sind ja auch Datenträger, wie meine Platte. Falls es im Forum doch einen bessenren Platz für mein Problem gibt, bitte ich um Vergebung und Verschiebung.


    Auf meinem RasPi3 mit aktuellem Jessi läuft eine Seafile-Cloud. Die Daten liegen auf eine 1TB-Platte, ext4-formatiert. Dort kann ich seit einigen Tagen nichts mehr schreiben oder Lösen.

    Nun habe ich festgestellt, dass die Platte wohl "vollgelaufen" ist.

    Code
    df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/root 7.2G 3.6G 3.5G 51% /
    devtmpfs 459M 0 459M 0% /dev
    tmpfs 463M 0 463M 0% /dev/shm
    tmpfs 463M 6.3M 457M 2% /run
    tmpfs 5.0M 4.0K 5.0M 1% /run/lock
    tmpfs 463M 0 463M 0% /sys/fs/cgroup
    /dev/mmcblk0p1 60M 20M 41M 34% /boot
    /dev/sda1 917G 871G 0 100% /media/platte

    Was aber im Gegensatz zur Seafile-Info steht, die besagt, dass Seafile nur 635,7 GB benutzt. Könnte aber sein, dass da der Seafile-eigene Papierkorb nicht mitgezählt wird.

    Dann habe ich die Platte ausgehängt und an einen Ubuntu-PC mit GParted gehängt: Platte: 931 GIB, benutzt: 885 GIB (95%), frei 46 GIB (5%) (Werte leicht gerundet. Also völlig andere Werte.


    Ich hänge mal die SMART-Werte an, ob evtl. die Platte defekt ist.

    Eigentlich nicht, aber vielleicht seht ihr mehr als ich.


    Es gibt außerhalb der Seafile-Ordners noch einen Ordner mit Dateien, die ich löschen könnte, um wenigstens einige Bit frei zu bekommen. Ich könnte mir vorstellen, dass dadurch die Platte wieder beschreibbar wird. Und sei es nur, um ein paar Löschbit zu setzen. Oder bin ich da auf dem Holzweg?


    Habt ihr eine Idee oder ist das doch ein "Seafile-Problem"?


    Viele Grüße

    DocAdams

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Ein EXT4 Filesysrem - egal ob auf HD, oder SD - ist "voll", wenn alle iNodes, oder alle Sektoren ( für normale User ) verbraucht sind.


    Ein privilegierter User hat noch einige Sektoren und iNodes zur Verfügung, so wie dies beim Anlegen des Ext4 FS (auch per default) -angegeben wurde.


    Im Header des Ext4 Filesystems (Superblock Information) können alle Ext4 Parameter u.A. mit dumpe2fs siehe < man dumpe2fs > angesehen weren, auch wer der privilegierte User ist, und wieviele iNodes sami Sektoren per iNodes er zu Verwaltung des Filesystems noch verwenden kann.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Doc

    Versuch mal im Dateimanager mit shift-entf eine Datei zu löschen. Vielleicht gelingt es, wenn nicht versucht wird, eine gelöschte Datei auf einer vollen Platte in den Papierkorb zu verschieben. Ein Versuch ist es wert.

  • Aus man mke2fs:
    ........

    -m reserved-blocks-percentage


    Specify the percentage of the filesystem blocks reserved for the

    super-user. This avoids fragmentation, and allows root-owned

    daemons, such as syslogd(8), to continue to function correctly

    after non-privileged processes are prevented from writing to the

    filesystem. The default percentage is 5%.


    Die 5 % sind genau Deine 46 GiB Differenz, die dem User root noch zur Verfügung stehen.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Vielen Dank für eure Antworten.

    Jetzt wird mir einiges klarer, zumindest wie es zu dem Problem kommen konnte. In der Seafilecloud sichere ich meine ganzen Videos, und da sind in den letzten 20 Jahren mehrere 100 GB zusammen gekommen. Dort hatte ich die Ordnerstruktur verändert und neu synchronisiert. Da ist vermutlich der Papierkorb übergelaufen. Ich hatte die Versionierung nicht deaktiviert. Ich hätte gedacht, dass dann die ältesten Dateien echt gelöscht werden.


    Es lässt sich nichts löschen, zumindest gelingt es mir nicht. Weder innerhalb des Seafilesystems, noch die paar Dateien, die "außerhalb" der Seafile-Datenbank in einem anderen Ordner für den Standard-User liegen. Auf die kann ich verzichten. In der Datenbank, die dem User "seafile" gehört, möchte ich im Terminal nichts löschen.

    Als Standard-User wollte ich mit

    Code
    sudo rm -r verzichtbarer Ordner/*

    ein paar Bit freischaufeln, vielleicht kann ich so die Versionierung in Seafile deaktivieren, um dann Ordner zu löschen, die nicht erst im Papierkorb landen.

    Bei den Dateien kommt als Antwort "Input/output error" und bei den Ordnern "No such file or directory"

    Es handelt sich um einen SAMBA-Ordner, wobei ich vor langer Zeit schon SAMBA deinstalliert hatte. Also vermutlich ein Rechteproblem....

    Ich bin mit Windows groß geworden, darum Sorry im Voraus, falls meine Idee zu naiv ist.

    Könnte ich mir eine größere Platte besorgen, mittels dd den Seafile-Ordner rüber kopieren und versuchen, die neue Platte in den RasPi einzubinden?

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Hallo DocAdams !


    Ich fürchte, dass Du den echten user root aktivieren musst, um die HD teilweise zu löschen.

    Es werden dabei massig Einträge ins Journal (und dessen Kopie) vorgenommen und die iNode Freelist umgeschrieben und davon werden noch Kopien behaltenm bis nicht alles als fehlerfrei gecheckt ist.


    Du kannst aber auch versuchen den EXT4 superuser root, = uid 0, auf uid=1000 gid=1000 mit tune2fs zu setzen, wenn der User pi "rw" Rechte auf die zu löschenden Dateien und Verzeichnisse besitzt, oder mit z.B. chown verschafft werden kann.


    Geänderte EXT4 Einstellungen müssen gesondert dem Kernel bekanntgemacht werden. Der Windows User macht dazu ein reboot.



    Servis !

    RTFM = Read The Factory Manual, oder so

  • sorry doc warum muss ich daran denken?


    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Mich verwirrt "kann nichts schreiben oder löschen"... Denn löschen ist auch schreiben ;)


    Was mir auch fehlt ist der Versuch etwas zu löschen und die dazugehörige Fehlermeldung. Copy&Paste aus der Konsole.



    Der G-Sense_Error_Rate SMART Werte deiner HDD steht auf 3 und könnte bedenklich sein:

    "Der Schock-Sensor misst die heftigen Erschütterungen im Betrieb. Zu starke Erschütterungen können ein mechanisches Berühren des Lese/Schreibkopfes auf die Platten auslösen. Ein Ausfall der Festplatte wäre die Folge."


    Evtl. ist deine Festplatte auch falsch formatiert... Da bin ich mir gerade nicht 100% sicher, aber soweit ich das zZt sehe handelt es sich bei der TOSHIBA MQ01UBD100 um eine 4-KByte-Sektoren Festplatte, du hast aber 512byte gesetzt. Also im Detail handelt es sich bei deiner Festplatte um eine 4KB mit Emulation (512e) aber da gibt es einige Besonderheiten zu beachten, Stichwort 4K-Alignment .

    Womit/Wie hast du die Partitionen erzeugt?

    Möglicherweise macht aber auch der verbaute Wandlerchip deines USB 3.0 Gehäuses Probleme...




    PS: Von der Festplatte gibt es einige Berichte wonach sie recht schnell sterben bzw ungewöhlich kurzlebig sind. Wenn du darauf wichtige Daten hast solltest du lieber regelmäßig ein Backup machen und dir langfristig etwas besseres besorgen, kein Toshiba.

  • Hallo und guten Abend,


    die Seafiledatenbank _sind_ meine Sicherungen, die Orginaldaten liegen also noch mal vor. Denen darf jetzt nichts passieren. Aber stimmt schon, gerade jetzt würde es sich "lohnen", kaputt zu gehen ;-/ Allerdings komme ich ja noch an den Stand von vor 10 Tagen ran. Ab dann geht nichts mehr Neues/Geändertes mehr. Also lesen kann ich die Daten noch und entsprechend runterladen.


    Die Fehlermeldung hatte ich oben verkürzt dargestellt. hier noch mal ein Ausschnitt:

    Code
    sudo rm -r /media/masse/samba/backup/*
    /bin/rm: cannot remove '/media/masse/samba/backup/superc/LW C/Users/Adam/AppData/Local/Packages/winstore_cw5n1h2txyewy/LocalState/Cache/0/0-ProductTileExtendedByProductGuid-https\342\210\272\342\210\257\342\210\257next-services.apps.microsoft.com\342\210\257browse\342\210\2576.3.9600-0\342\210\257788\342\210\257de-DE_de-DE\342\210\257c\342\210\257DE\342\210\257cp\342\210\25710005001\342\210\257Apps\342\210\257f231ded2-c998-4f61-83af-8d72dde7651d.dat': Input/output error
    ...
    /bin/rm: cannot remove '/media/masse/samba/backup/super/LW D/Raspberry-Scripte/SAMBA/151218/seafile/seafile-server-5.0.2/seahub/static/scripts/app/views/organization.js': Input/output error
    ...
    /bin/rm: cannot remove '/media/masse/samba/backup/super/LW D/Raspberry-Scripte/SIMBA/151218/seafile/seaf0.2/seahub/thirdpart/flup-1.0-py2.7.egg/flup/client/': No such file or directory

    Also entweder "Input/output error" oder "No such file or directory"


    Die Platte ist ext4-formatiert und funktioniert so schon mehrere Jahre. Eigentlich _glaube_ ich nicht dass sie mechanisch defekt ist, z.B. durch einen Stoß. Ich glaube eher, dass sie "voll" gelaufen ist, wie Jar vermutet. Mir ist schon klar, Glaube hat hier nichts zu suchen...

    Falls doch die Platte hin ist oder beginnt, sich zu verabschieden, muss ohnehin eine Neue ran. Nach mehreren Jahren waren das aber vor dem Problem vielleicht 500GB. Also wäre ich mit der 1TB-Platte noch lange zufrieden gewesen.

    Ich komme noch mal zu der Idee zurück, eine größere Platte zu kaufen, die Partition rüber zu kopieren und zu erweitern, damit Seafile wieder Platz zum Schreiben hat. Ist das überhaupt realistisch, oder von vornherein Quatsch?


    Ich frage das deshalb, weil ich keiner bin, der sich unbedingt riesige Platten anschafft, um sie dann nur ansatzweise auszufüllen. Auch wenn die Preisunterschiede nicht mehr so tödlich sind, wie vor Jahren.

    Viele Grüße

    DocAdams

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Du kannst den root-reserved space jederzeit ändern.

    sudo tune2fs -m 0 /dev/sda1

    Ob sich dein Problem damit löst ...

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Ich weiß, ihr seid Linuxprofis (ich meine das wirklich eher bewundernd, um nicht zu sagen beneidend), aber ehe ich nicht sicher bin, dass ich ohnehin alles neu aufsetzen muss, traue ich mich nicht ran, an der Plattenstruktur was zu drehen.

    Oder ist meine Idee völlig abwegig? Wenn nicht, würde ich mir eine 2TB-Platte bestellen.


    llutz:

    wenn ich Ubuntuusers richtig verstanden habe, möchtest du die reservierten Blöcke auf 0% setzen. Was von Ubuntuusern nicht empfohlen wird.

    Wie RTFM oben sagt, sind es 5% reservierte Blöcke.

    Wäre es besser, die erst mal auf 4.5% zu setzen? Vielleicht kann ich dann die Versionierung ausschalten? Ich vermute, dass das der Grund ist, dass die Platte voll gelaufen ist. Aber ich kann den Parameter nicht ändern, weil das vermutlich auf der Platte gespeichert wird, nicht im Programm Seafile, das sich auf der SD-Karte im RasPi befindet.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Die default 5% root reserve ist auf reinen Datendateisystemen Unsinn, setze die auf 0 oder wenn du meinst auf 1% und gut.

    Zu Zeiten von Dateisystemen im MB-Bereich waren 5% OK, heute ist das eine sinnfreie Vergeudung (wenn auch günstigen) Plattenplatzes. Sinnvoll war/ist diese Reserve allerdings ohnehin nur auf /, /tmp und /var.

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Hallo DocAdams


    Warum jammerst Du herum und änderst nicht den Superuser root der EXT4 Partition auf der Platte, auf den user pi, oder einen anderen, der dann (seine) Dateien löschen und umorganisieren kann ?


    sudo rm fuht zwar mit root Rechten einen Befehl aus, die urspüngliche Prozess ID (und der aufrufende User Pi) wird aber nur, wie bei einem Link überdeckt, was am + Zeichen des Prozesses zu erkennen ist. Nur die echte uid 0 kann den reservierten Speicherplatz (5 %) noch nutzen, wenn uid 0 als privilegierter Nutzer im EXT4 Header eingetragen ist. uid 1000 könnte dies, wenn der ptivilegierte User (mit tunefs) auf uid1000 gid 1000 geändert wird.


    Bei enem Löschbefehl auf EXT4 werden, einfach gesagt, alle Systemtables einmal kopiert, die entsprechenden iNodes als (wieder) frei markiert und in die freie Inode Liste aufgenommen. Die schon recht grosse iNode Tabelle wird - ohne freie Inodes - neu aufgebaut und, wenn alles fehlerfrei abgelaufen ist, werden alle Kopien wieder gelöscht. Schon für das Anlegen diverser Sicherungskopien hat der aufrufende user pi (auch nicht als sudoer) Rechte. Die Platte ist einfach (nur) voll, dh alle für normale User bestimmte Sektoren oder iNodes sind verbraucht.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • sudo -i

    und schon ist man root mit UID=0, da braucht man am FS nix ändern.

    df -i

    zeigt einem den Stand der belegten Inodes an.

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Bei den Dateien kommt als Antwort "Input/output error" und bei den Ordnern "No such file or directory"

    Es handelt sich um einen SAMBA-Ordner, wobei ich vor langer Zeit schon SAMBA deinstalliert hatte. Also vermutlich ein Rechteproblem....

    Das klingt eher nach kaputt als nach nem Rechteproblem

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Code
    df -i
    Filesystem Inodes IUsed IFree IUse% Mounted on
    /dev/root 455952 241598 214354 53% /
    devtmpfs 117422 346 117076 1% /dev
    tmpfs 118501 1 118500 1% /dev/shm
    tmpfs 118501 451 118050 1% /run
    tmpfs 118501 4 118497 1% /run/lock
    tmpfs 118501 10 118491 1% /sys/fs/cgroup
    /dev/mmcblk0p1 0 0 0 - /boot
    /dev/sda1 61054976 1337003 59717973 3% /media/masse

    Da müsste ich noch wahnsinnig viel frei haben??? I verstehs net.

    Viele Grüße
    DocAdams

    1x RaspberryPi 2, 1x RaspberryPi 3, 1x OpenELEC, 1x RaspberryPi 4 mit ioBroker ,

  • Mach einfach ein < sudo tune2fs -u pi /dev/sda1 > oder

    < sudo tune2fs -u 1000 /dev/sda1 >

    dann ein umount oder reboot

    und arbeite als user pi unbeschwert bis zum geht nicht mehr weiter.

    Wenn die Kopien der Systemtabellen vor dem Schreiben oder löschen nicht mehr angelegt werden können, meldet sich die Platte eh wieder.

    Dann ist aber auch mit dem Löschen schluss und Du musst weitere EXT4 Parameter ändern.


    Servus !

    RTFM = Read The Factory Manual, oder so