Kann nicht auf halb voller Festplatte schrieben - rootkit?

[DerNeue]

Hallo,

bekomme bei allem möglichen die Meldung, daß meine Festplatte voll sei, und nicht auf Ihr geschrieben werden könne.
Beispiel:
"Auf dem Gerät ist kein Speicherplatz mehr verfügbar"

Das ist aber Unsinn, da die Platte erst 1/2 - 3/4 voll ist.

Ich fürchte, ich habe ein rootkit drauf Kann ich noch irgendwas machen - außer den Rechner zum Fenster rauswerfen, bzw ins RZ fahren die Platte einige Stockwerke hochtragen und dann zum Fenster rauswerfen

Ich meine, so ein rootkit muß meinem Server doch auch sagen: "Nö, ab jetzt lüg dem Markus immer vor, daß die Platte voll ist!" Wo kann man denn sowas machen?

Gruß
DerNeue

[Mr. Rabbit]

Moin moin,,

gib doch bitte mal den Befehl

Code: Alles auswählen

# df -h

und

Code: Alles auswählen

# df -i

ein und poste das Ergebnis.

[DerNeue]

Morgen,

Code: Alles auswählen

df -h:

Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/hda1              37G   25G  9,6G  73% /
tmpfs                 248M     0  248M   0% /dev/shm

Code: Alles auswählen

df -i:

Dateisystem           INodes  IBenut.  IFrei IBen% Eingehängt auf
/dev/hda1            4840192 4840192       0  100% /
tmpfs                  63445       1   63444    1% /dev/shm

Mmmh, was heißt das?

Der Neue

[DerNeue]

Nachtrag:

Mache mich grad schlau, was es mit den Inodes auf sich hat. Denke hab das soweit verstanden. Es liegt da also pro File ein Inode? Hab grad mal ein paar kleine Files gelöscht und siehe da, es werden Inodes frei. Und es läßt sich eine neue Textdatei ohne Meckerei erstellen.

Kann ich das irgendwie besser tunen? Das ist so doch irgendwie Murx.

Hier mal mein tune2fs(Hoffe, es ist nicht zu lang)

Code: Alles auswählen

tune2fs -l /dev/hda1
+tune2fs 1.37 (21-Mar-2005)
Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          3b5652f5-719a-4896-86ac-d1968f47d7f0
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4840192
Block count:              9671122
Reserved block count:     483556
Free blocks:              2998766
Free inodes:              0
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16352
Inode blocks per group:   511
Last mount time:          Fri Dec 30 02:50:11 2005
Last write time:          Fri Dec 30 02:50:11 2005
Mount count:              8
Maximum mount count:      30
Last checked:             Thu Jan  1 01:00:00 1970
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       3332727
Journal backup:           inode blocks

Die inodes sind doch eigentlich schon mickrig gewählt. Was kann ich tun - außer aufräumen?

Puh, da bin ich jetzt aber etwas erleichtert. Hielt mich schon für den Oberpfuscher! Jetzt läuft auch mein Indianer wieder

Gruß
DerNeue

[nil]

Die Inode-Angaben sollten eigentlich bei einer Standard-Installation in Ordnung gehen. Es gibt Gründe die Inode-Anzahl zu erhöhen, wenn viele kleine Dateien vorhanden sind.
Mein System nutzt z.Z. nur 14 Prozent der Inodes bei 36 % Festplattenbelegung.

Frage: hast du vielleicht eine Anwendung wie Squid (Proxy) installiert. Wenn ja, solltest du nicht jede kleine Datei cachen, sondern nur Files ab einer bestimmten Größe. Versuch herauszufinden, in welchem Ordner die meisten Dateien rumliegen.
Alternativ kannst du auch vielleicht noch mal unter /tmp oder /var suchen.

[Mr. Rabbit]

Ich bin mir nicht sicher, ob ein Erweitern von Inodes im laufenden Betrieb möglich ist - meines Wissens nach kann man die Anzahl nur bei der Initialisierung eines Dateisystems angeben

Btw. Wenn Du Dienste wie zB. Proxy oder Webserver auf der Maschine laufen lässt ist es sinnvoll, zumindest /var auf eine extra Partition zu legen, denn so besteht nicht die Gefahr, dass Dein Root-Filesystem (/) mit logfiles überflutet und dadurch unbrauchbar wird.

[DerNeue]

Also mir ist schon ungefähr klar, woher die ganzen Dateien kommen.
Da viele meiner PHP-Scripte AdoDB und seine Caching-Funktionen nutzen gibts Unmengen an micker Text-Dateien. Außerdem hab ich ne Menge Seiten...

ist es sinnvoll, zumindest /var auf eine extra Partition zu legen

Geht das im laufenden Betrieb?

Es gibt Gründe die Inode-Anzahl zu erhöhen, wenn viele kleine Dateien vorhanden sind.
Mein System nutzt z.Z. nur 14 Prozent der Inodes bei 36 % Festplattenbelegung.

Wie groß sind Deine inodes gewählt? Was ist jetzt bei vielen kleinen Textdateien ein guter Wert für die inodes?

Danke für Eure Hilfe
DerNeue

[nil]

Gerechnet auf die Platte ist es gleich, die Platte ist nur kleiner.

Aber versuch doch mal:

Code: Alles auswählen

find /var -size +1k 
find /var -size -1k

natürlich auch für andere Verzeichnisse, evtl. mit " | wc " durchzählen.

Edit: evtl. auch 1000c für 1000 Bytes ... oder kleiner bzw. größer.

[KBDCALLS]

Ich bin mir nicht sicher, ob ein Erweitern von Inodes im laufenden Betrieb möglich ist - meines Wissens nach kann man die Anzahl nur bei der Initialisierung eines Dateisystems angeben
.

Neuformat. Anders gehts nicht.

[KBDCALLS]

Nachtrag:

Mache mich grad schlau, was es mit den Inodes auf sich hat. Denke hab das soweit verstanden. Es liegt da also pro File ein Inode? Hab grad mal ein paar kleine Files gelöscht und siehe da, es werden Inodes frei. Und es läßt sich eine neue Textdatei ohne Meckerei erstellen.

Kann ich das irgendwie besser tunen? Das ist so doch irgendwie Murx.

First orphan inode: 3332727

orphan = verwaist

Wie kommt das hierzu ?

Nimm dir mal ne Knoppix und lass mal

fsck -f -v /dev/hd1 laufen.

http://nopaste.debianforum.de/1984

[DerNeue]

Gerechnet auf die Platte ist es gleich, die Platte ist nur kleiner.

Aber versuch doch mal:....

Ja, hab ich gemacht. Wie ich es mir gedacht hab. Ich hatte einen cache-Ordner pro Projekt und das freundliche AdoDB hat das exzessiv ausgenutzt!

Nimm dir mal ne Knoppix und lass mal

fsck -f -v /dev/hd1 laufen.

Leider steht der Rechner nicht bei mir. Und ohne Knoppix sieht es dann so aus

Code: Alles auswählen

WARNUNG!!!  Die Benutzung von e2fsck auf einem eingehängten
Dateisystem kann das Dateisystem STARK BESCHÄDIGEN.

Wirklich fortfahren (j/n)? nein

Da hab ich mich nicht getraut

Gibt es da noch eine andere Möglichkeit?

Gruß und Danke
derNeue

[KBDCALLS]

Das geht nicht anderes , wenn fsck läuft darf die Platte nicht gemountet sein. Das ist normal das er sich dann weigert. Und die Warnung sollte man auch durchaus ernst nehmen.

[schoeppchen]

Wo steht denn der Rechner? Normalerweise gibt es ja immer eine Rescuekonsole für solche Zwecke bzw. je nach Anbieter die Möglichkeit, dass auch von nem Admin vor dem Rechner selbst durchführen zu lassen. Ich würde das auch nicht verharmlosen!

[DerNeue]

Wo steht denn der Rechner?

Irgendwo in Frankfurt 200m Luftlinie zum RedBus Colocation Datacenter in einem anderen Datacenter

Ich würde das auch nicht verharmlosen

Was richtet so ein oder mehr verwaiste inodes an?

Bin übrigens inzwischen auf "nur noch" 70% inodes.

Gruß
DerNeue

[schoeppchen]

Naja, die verwaisten Inodes erst mal gar nix, die zeigen schlichtweg nur noch wohin, wo nix mehr ist. Aber das Ganze hat ja ne Ursache und diese verdsuchst du ja evtl. mit einem fsck zu beheben bzw. zu finden. Evtl. auch mal mit smartmontools die Platte scannen, das läuft auf dem Controller und kann zu jeder Zeit gestartet werden ohne dass deine Platte Schaden nehmen sollte.

[KBDCALLS]

Ich meinte auch mehr dieses hier

WARNUNG!!! Die Benutzung von e2fsck auf einem eingehängten
Dateisystem kann das Dateisystem STARK BESCHÄDIGEN.

Wirklich fortfahren (j/n)? nein

Man stelle sich nur mal zwei Schreibzugrffe finden auf der gleichen Stelle statt.