Für automatisierte Auswertung das GNU df(1) bitte nur mit dem Switch -P bzw. --portability benutzen:

Quote

`-P'
`--portability'
    Use the POSIX output format.  This is like the default format
    except for the following:

      1. The information about each file system is always printed on
         exactly one line; a mount device is never put on a line by
         itself.  This means that if the mount device name is more
         than 20 characters long (e.g., for some network mounts), the
         columns are misaligned.

      2. The labels in the header output line are changed to conform
         to POSIX.

[quote=opi,25.05.2007, 17:11]
Wonach sieht das für dich aus sid? ;)[/quote]
sieht das genauso aus, wenn du es mit qx// einliest? ich
würde mal vermuten, dass das für die anzeige in einem terminal
umgebrochen wird, und wenn df merkt, dass es nicht an ein terminal
printet, dann bricht es nicht um.

[quote=Dubu,25.05.2007, 18:20]Für automatisierte Auswertung das GNU df(1) bitte nur mit dem Switch -P bzw. --portability benutzen:[/quote]
warum mache ich es mir dann so umständlich? *argh*

hast du schonmal erlebt, dass es den schalter -P auf ner distro nicht gibt?

man weiß ja nie... ansonsten bau ich das gerne ein :)

[quote=pq,25.May.2007, 18:32][quote=opi,25.05.2007, 17:11]
Wonach sieht das für dich aus sid? ;)[/quote]
sieht das genauso aus, wenn du es mit qx// einliest? ich
würde mal vermuten, dass das für die anzeige in einem terminal
umgebrochen wird, und wenn df merkt, dass es nicht an ein terminal
printet, dann bricht es nicht um.[/quote]
Jup sieht es.
Und normalerweise ist es ja auch nur so das Zeilen im Terminal umgebrochen werden. Aber bei 'df' nicht, wenn man es in eine Datei umleitet hat man den selben umbruch drin. Genau deswegen sagte ich ja das es "beschie***' Programmiert ist.

Quote

warum mache ich es mir dann so umständlich? *argh*
hast du schonmal erlebt, dass es den schalter -P auf ner distro nicht gibt?
man weiß ja nie... ansonsten bau ich das gerne ein

Hmm, du liest in deinem Modul die Ausgabe von 'df' ?
Gibt es da keine bessere Möglichkeit an die Daten zu kommen?

z.B. über /proc oder /sys ?

[quote=sid burn,26.05.2007, 01:04]Hmm, du liest in deinem Modul die Ausgabe von 'df' ?
Gibt es da keine bessere Möglichkeit an die Daten zu kommen?

z.B. über /proc oder /sys ?[/quote]
Japp korrekt. Ich lese alle Statistiken aus /proc - so machen
es ja auch alle gängigen Befehle wie zum Beispiel ps, sar,
iostat, vmstat etc., aber Plattenbelegung ist das Einzige,
was man dort nicht finden kann. Man kann bzgl Platten nur
Statistiken für Schreib- und Lesezugriffe auswerten.

Warum das so ist... dafür gibt es einige Gründe... ein Grund
ist zum Beispiel, das es zuviel arbeit für den Kernel wäre,
dauernd die aktuelle Größe jeder Platte zu kontrollieren und
für /proc bereitzustellen. Denk dir einfach mal zum Beispiel
SAN-Space oder anderweitiges Sharing, wo mehrere Systeme
auf die gleichen Platten schreiben. Du fragst Server A nach
der Plattenbelegung und Server B schreibt und löscht fleißig
vom Filesystem... wie soll Server A das mitbekommen und
seine proc-Daten aktualisieren? Pollen? Ne, das wäre echt
zuviel. Die Befehle "df" und "du" lesen immer den aktuellen
Stand der Platten aus.

Hattest du zum Beispiel noch nie das Phenomän, dass der
Befehl df hängt, wenn ein globales Filesystem Probleme macht?
Oder wenn der Samba oder NFS-Dienst versagt? Dann muss
man oftmals den Befehl abbrechen...

Es gibt noch weitere Gründe, aber die findest du unter Mr.
Google :)

Ich könnte also irgendwas in C schreiben, aber wofür? df reicht
mir da vollkommen aus.\n\n

<!--EDIT|opi|1180135948-->

[quote=opi,26.05.2007, 01:25]Ich lese alle Statistiken aus /proc - so machen
es ja auch alle gängigen Befehle wie zum Beispiel ps, sar,
iostat, vmstat etc., aber Plattenbelegung ist das Einzige,
was man dort nicht finden kann.[/quote]
man 2 statfs

[quote=opi,26.05.2007, 01:25]das es zuviel arbeit für den Kernel wäre,
dauernd die aktuelle Größe jeder Platte zu kontrollieren und
für /proc bereitzustellen.[/quote]
Sachen in /proc werden nicht dauernd bereitgestellt... Sie werden in dem Moment erzeugt, in dem Du sie ausliest (siehe z. B. /usr/src/linux/fs/proc/proc_misc.c).  Es waere imho keinerlei Performance-Einbuße, ueber das proc-Dateisystem die Information bereitzustellen, die auch ueber statfs bereitgestellt wird.\n\n

<!--EDIT|betterworld|1180182804-->

[quote=betterworld,26.05.2007, 14:24]man 2 statfs[/quote]
was hat statfs denn nun mit meiner aussage zu tun, dass man
Plattenbelegung nicht über /proc auslesen kann?

[quote=betterworld,26.05.2007, 14:32]Sachen in /proc werden nicht dauernd bereitgestellt... Sie werden in dem Moment erzeugt, in dem Du sie ausliest (siehe z. B. /usr/src/linux/fs/proc/proc_misc.c).[/quote]
Das ist nichts neues. Jedoch werden gewisse Statistiken vom
Kernel ab Systemstart gezählt und werden dann auf Abruf
bereitgestellt.

[quote=betterworld,26.05.2007, 14:32]Es waere imho keinerlei Performance-Einbuße, ueber das proc-Dateisystem die Information bereitzustellen, die auch ueber statfs bereitgestellt wird.[/quote]
Es ist imho so, dass Plattenbelegung nicht unter /proc
bereitgestellt wird.\n\n

<!--EDIT|opi|1180186392-->

[quote=opi,26.05.2007, 15:21][quote=betterworld,26.05.2007, 14:24]man 2 statfs[/quote]
was hat statfs denn nun mit meiner aussage zu tun, dass man
Plattenbelegung nicht über /proc auslesen kann?[/quote]
So direkt eigentlich nichts.  Ich hatte Dich nur so verstanden, dass nirgends ein Zaehler existiert, der mitzaehlt, wie viele Blocks frei sind.  Es existiert aber einer, und man kan ihn mit statfs abfragen (bei Remote-Dateisystemen wird die Abfrage dann wahrscheinlich weitergeleitet).

Quote

Die Befehle "df" und "du" lesen immer den aktuellen
Stand der Platten aus.

df benutzt auch statfs.  du hingegen geht rekursiv ueber eine Verzeichnisstruktur und zaehlt alle Groessen zusammen.  Daher ist df auch schneller als du.