Harry Rüter wrote:
Da kann es dann passieren, daß obwohl ich 200 MB lösche, ein df -h anzeigt, daß die Partition zu 100% voll ist.
Hat das was mit ext3 zu tun ?
Der Punkt an der Sache, den man hier ruhig noch einmal erwähnen sollte, ist, daß unter UNIX eine Datei erst dann gelöscht wird, wenn ihr Link-Count gleich Null ist (d.h. es gibt keinen Verzeichniseintrag mehr dafür) UND der Open-Count gleich Null ist (d.h. kein Prozeß hat diese Datei noch offen. Solange irgend ein (Hard-)Link noch darauf zeigt oder irgend ein Prozeß sie geöffnet hatte, ist sie noch auf der Platte. Ich z.B. habe oft ein "tail -f /var/log/messages" laufen. Wenn ich jetzt syslog anhalte und /var/log/messages lösche (genauer gesagt: mit rm den letzten Verzeichniseintrag dafür entferne), gibt es die Datei noch und sie verbraucht immer noch Platz, obwohl sie in keinem einzigen Verzeichnis mehr zu sehen ist ! -- Eckhard Rüggeberg E.Rueggeberg@t-online.de - Who is General Failure, and why is he reading my disk ??
Hi, Eckhard Rüggeberg wrote:
Harry Rüter wrote:
Da kann es dann passieren, daß obwohl ich 200 MB lösche, ein df -h anzeigt, daß die Partition zu 100% voll ist.
Hat das was mit ext3 zu tun ?
Der Punkt an der Sache, den man hier ruhig noch einmal erwähnen sollte, ist, daß unter UNIX eine Datei erst dann gelöscht wird, wenn ihr Link-Count gleich Null ist (d.h. es gibt keinen Verzeichniseintrag mehr dafür) UND der Open-Count gleich Null ist (d.h. kein Prozeß hat diese Datei noch offen. Solange irgend ein (Hard-)Link noch darauf zeigt oder irgend ein Prozeß sie geöffnet hatte, ist sie noch auf der Platte.
Genau das ist die Lösung !!!
Ich z.B. habe oft ein "tail -f /var/log/messages" laufen. Wenn ich jetzt syslog anhalte und /var/log/messages lösche (genauer gesagt: mit rm den letzten Verzeichniseintrag dafür entferne), gibt es die Datei noch und sie verbraucht immer noch Platz, obwohl sie in keinem einzigen Verzeichnis mehr zu sehen ist !
Exakt !!! Ein bischen OT, aber sollte das rm-Komando in dem Fall nicht darauf hinweisen, daß der Speicherplatz nicht freigegeben wird (und dann Link/Opencount irgendwie angeben) ?
-- Eckhard Rüggeberg E.Rueggeberg@t-online.de
Danke für die Lösung, hatte mir echt Kopfzerbrechen bereitet, dabei ist es manchmal so einfach (und auch logisch) Gruß Harry
* Harry Rüter schrieb am 27.Aug.2002:
Ein bischen OT, aber sollte das rm-Komando in dem Fall nicht darauf hinweisen, daß der Speicherplatz nicht freigegeben wird (und dann Link/Opencount irgendwie angeben) ?
Und wie soll das rm machen? Ob es noch Hardlinks gibt, kann man mit ls -l sehen. Aber woher der Link kommt geht nur mit ls -i die I-Node merken und dann find Mountpoint -xdev -inode I-Node Beschwer Dich aber nicht, wenn es länger dauert. ;) Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Am Dienstag, 27. August 2002 13:48 schrieb Bernd Brodesser:
find Mountpoint -xdev -inode I-Node
kannst Du diesen Befehl mal ein wenig näher erläutern ? cu stonki -- deutsche ProFTPD Dokumentation: http://www.proftpd.de http://krename.sf.net http://kbarcode.sf.net
On 27 Aug 2002 at 14:07, Stefan Onken wrote:
Am Dienstag, 27. August 2002 13:48 schrieb Bernd Brodesser:
find Mountpoint -xdev -inode I-Node
kannst Du diesen Befehl mal ein wenig näher erläutern ?
find <dir> -xdev -inum I-Node oder find <dir> -mount -inum I-Node wäre wohl (laut man find) korrekter. Aber das wusstest du schon als Du gefragt hast, oder? Andreas
* Andreas Kyek schrieb am 27.Aug.2002:
find <dir> -xdev -inum I-Node
oder
find <dir> -mount -inum I-Node
wäre wohl (laut man find) korrekter. Aber das wusstest du schon als Du gefragt hast, oder?
Dabei muß <dir> aber ein Mountpoint sein, sonst hat es keinen Sinn. Ein Hardlink muß nicht vom gleichen Verzeichnis aus erfolgen, sondern kann von überall her kommen. Allerdings im gleichen Dateisystem. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
* Stefan Onken schrieb am 27.Aug.2002:
Am Dienstag, 27. August 2002 13:48 schrieb Bernd Brodesser:
find Mountpoint -xdev -inode I-Node
kannst Du diesen Befehl mal ein wenig näher erläutern ?
Du must vorher feststellen, welche I-Node Du suchst. Dazu machst Du ls -i. Angenommen, es geht um die Datei /tmp/foo dann bekomst Du mit ls -i /tmp/foo folgende Ausgabe: 435 /tmp/foo 435 ist natürlich nur ein Beispiel. Die Inode ist nur in einem Dateisystem eindeutig. Wenn Du mehere Dateisysteme (Partitionen) hast, dann mußt Du weiter Einschränken. Angenommen Du hast für /tmp eine eigene Partition, so lautet der Befehl: find /tmp -inode 435 und Du bekomst alle Hardlinks zu /tmp/foo. /tmp/foo selber ist natürlich auch dabei, denn es gibt bei Hardlinks keinerlei Unterschied zwichen Link und Original. Es läßt sich nachträglich nicht feststellen, was das Original, und was der Link ist. Wenn es noch andere Untersysteme unterhalb Deines Mountpoint geben sollte, ist bei /tmp zwar unwahrscheinlich, aber wenn da / oder vielleicht auch /usr steht, so könnte das ganz gut sein, so muß noch -xdev mitgegeben werden, damit nicht in die andere Systeme gesucht wird. find /tmp -xdev -inode 435 /tmp muß ein Mountpunkt sein, wen bei Dir /tmp, oder wo Du auch immer suchst, nicht auf eine eigene Partition liegt, so muß der Befehl: find / -xdev -inode 435 lauten. 435 ist wie gesagt nur ein Beispiel. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hi, Bernd Brodesser wrote:
* Harry Rüter schrieb am 27.Aug.2002:
Ein bischen OT, aber sollte das rm-Komando in dem Fall nicht darauf hinweisen, daß der Speicherplatz nicht freigegeben wird (und dann Link/Opencount irgendwie angeben) ?
Und wie soll das rm machen? Ob es noch Hardlinks gibt, kann man mit ls -l sehen. Aber woher der Link kommt geht nur mit ls -i die I-Node merken und dann
find Mountpoint -xdev -inode I-Node
Beschwer Dich aber nicht, wenn es länger dauert. ;)
Da hat du mich falsch verstanden. Sowas wie: rechner: # rm xyz warning: link/opencount not zero, inodes will not be free until link/opencount is zero. rechner: # rm xyz Würde doch schon helfen. Denn Rest solte man selbst hinkriegen. Wie das dann bei Programmen geht, die das Löschen mittels syscall (in der libc ?) ausführen weiß ich nicht .. Aber das würde jetzt zu weit führen.
Bernd
Gruß Harry
* Harry Rüter schrieb am 27.Aug.2002:
Bernd Brodesser wrote:
Und wie soll das rm machen? Ob es noch Hardlinks gibt, kann man mit ls -l sehen. Aber woher der Link kommt geht nur mit ls -i die I-Node merken und dann
find Mountpoint -xdev -inode I-Node
Beschwer Dich aber nicht, wenn es länger dauert. ;)
Da hat du mich falsch verstanden. Sowas wie:
rechner: # rm xyz warning: link/opencount not zero, inodes will not be free until link/opencount is zero. rechner: # rm xyz
Und wie willst Du einen link löschen, wenn jedesmal eine Warnmeldung kommt und nicht löscht?
Würde doch schon helfen. Denn Rest solte man selbst hinkriegen. Wie das dann bei Programmen geht, die das Löschen mittels syscall (in der libc ?) ausführen weiß ich nicht ..
Es wird der Systemaufrum unlink benutzt. Siehe man unlink Der macht genau das, worüber hier gesprochen wird, nämlich den Eintrag aus dem Verzeichnis nehmen, und den Linkzähler um eins vermindern. Wenn er dadurch auf 0 kommt, trägt der Kernel die Blöcke in die freie Blöcke ein. Wirklich gelöscht wird gar nicht. Daß heißt, die Datenblöcke werden nicht überschrieben. Sie können gelesen werden, wenn man direkt auf die Device geht. Ist nicht einfach, und lohnt normalerweise nicht, aber für Spione unter Umstände schon. Ansonsten schreib Dir doch ein Shellskript, das ls -l auswertet, und Dir eine Warnung gibt. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
On Die, 27 Aug 2002 at 15:02 (+0200), Harry Rüter wrote:
Bernd Brodesser wrote:
* Harry Rüter schrieb am 27.Aug.2002:
Ein bischen OT, aber sollte das rm-Komando in dem Fall nicht darauf hinweisen, daß der Speicherplatz nicht freigegeben wird (und dann Link/Opencount irgendwie angeben) ?
Und wie soll das rm machen? Ob es noch Hardlinks gibt, kann man mit ls -l sehen. Aber woher der Link kommt geht nur mit ls -i die I-Node merken und dann
find Mountpoint -xdev -inode I-Node
Beschwer Dich aber nicht, wenn es länger dauert. ;)
Da hat du mich falsch verstanden. Sowas wie:
rechner: # rm xyz warning: link/opencount not zero, inodes will not be free until link/opencount is zero. rechner: # rm xyz
Würde doch schon helfen. Denn Rest solte man selbst hinkriegen.
Unix-Philosophie: No message is a good message. rm soll den I-Node-Eintrag entfernen - das klappt. Um den Rest muss sich der Anwender selbst kümmern bzw. mit Hilfe geeigneter Werkzeuge (ls, lsof) die Bedingungen dafür schaffen, dass die Datei restloc verschwinden soll. Woher soll rm wissen, dass Du _alle_ Links der Datei löschen willst? Der andere Punkt (Datei durch anderen Prozess geöffnet): Entweder rm haut nur die Inode weg (und so arbeitet er ja), oder er klaut dem anderen Proozess die offene Datei unter dem Hintern weg (-> Prozessabbruch?) oder er kriegt eine systemweit genutzte Datei nie gelöscht, weil ständig irgendein Prozess drauf zugreift - auch Mist. So wie es läuft, ist es schon ok. Der Prozess kann weiter in die Datei schreiben, der nächste legt sie neu an. Laufende Prozesse werden nicht beeinträchtigt und die Systemwartung funktioniert trotzdem. Unix geht immer davon aus, dass der Anwender weiß, was er macht. Jan
participants (6)
-
Andreas Kyek -
B.Brodesser＠t-online.de -
Eckhard Rüggeberg -
Harry Rüter -
Jan.Trippler＠t-online.de -
Stefan Onken