|
Anzeige
|
Raspian - gesamten freien Speicher der SD-Karte anzeigenIch suche ein Terminal-Kommando, welches den gesamten freien Speicher auf der SD-Karte eines Raspberry als einzige Zahl anzeigt. Das immerzu mir empfohlene "df -h" liefert statt dessen eine Liste, mit der ich im konkreten fall nichts anfangen kann. Natürlich könnte ich mir die Info auch zusammen-parsen, aber das geht doch bestimmt auch gleich als EINE Zahl, oder? Danke für Tips. :
Bearbeitet durch User
df -h / | awk 'NR==2 {print $4}' ^Filesystem ^Zeile ^Spalte :
Bearbeitet durch User
Alternativ, nach Lektüre von man df kommt man auf df --output=avail -h / | tail -n1 :
Bearbeitet durch User
Gibt die Anzahl der (für User) freien (meist 4k) Blöcke aus. stat kennt die Blockgröße auch selbst, '%S' um die auszugeben. d.H., für die freien Bytes:
Den bc müsste er allerdings nachinstallieren. Heftige Aufgabe. :) :
Bearbeitet durch User
Danke! Hab mich für die Variante von Ernst B. entschieden.
Was bringt das eigentlich? Üblicherweise sind die Karten partitioniert, wenn da ein Linux drauf läuft, und man kann nur den Platz einzelner Partitionen, nicht aber partitionsübergreifend nutzen. Auf jeden Fall gibt es eine FAT32-Partition, und eine oder mehrere meist mit Exfts(nummer) formatierte Partitionen. Die FAT32-Partition ist nötig, damit die GPU-Hardware davon booten kann, dort liegt auch die berühmte "config.txt".
Den freien Platz auf dem Root-FS. Auf welcher Partition auch immer es liegen mag. Das ergab die Exegese seiner Frage. Mit der Summe aller freien Plätze auf sämtlichen Filesystemen kann man meist nicht sonderlich viel anfangen. :
Bearbeitet durch User
OK, dann hatte ich da was missverstanden. Ja, genau das ist die einzig sinnvolle Angabe.
Der folgende Satz könnte darauf hindeuten, dass der TE genau das möchte:
Bei der Bestimmung des /gesamten/ freien Speichers auf der SD-Karte müssten zusätzlich auch nicht gemountete Filesysteme, unformatierte Partitionen und unpartitionierte Bereiche berücksichtigt werden.
Das wiederum lässt vermuten, dass das Root-Filesystem ausreicht. Falls nicht, sollte der TE seinen Wunsch etwas genauer spezifizieren.
Oder dass er den Schritt von df -h zu df -h / nicht schaffte. So hatte ich das in Erinnerung an frühere Fragen interpretiert. Da der von ihm favorisierte Vorschlag von Ernst die Grösse in Blöcken oder Bytes angibt, will er eigentlich nicht einmal das -h von "df", sondern eher -B aka --block-size. :
Bearbeitet durch User
Hätte da noch einen späten Nachtrag. Wusste dass ich so etwas schonmal vor mehr als tausend Monden in ein Shell Script massiert hatte:
Ergebnis in Bytes:
:
Bearbeitet durch User
df -h .
Ich wollte gerne EINE Zahl (ja, vom root system), was auch df -h / nicht leistet, sondern noch überflüssige Prosa anheftet, siehe Bild. "df -h ." ist auch nicht besser. Der Vorschlag von Ernst B. liefert tastsächlich nur eine nackte Zahl, sonst nix, genau richtig. Auch wenn ich zur Sicherheit wegen der Blockgröße zwei mal abfrage. Passt perfekt.
Angehängte Dateien:
:
Bearbeitet durch User
Beitrag #7927913 wurde vom Autor gelöscht.
Nö, nur ziemlich unpraktisch bei dutzenden laufenden Raspis. Es genügt vollkommen, das Shell-Kommando in die ohnehin laufende (und regelmäßig aktualisierte) App zu integrieren. :
Bearbeitet durch User
Unnötig trifft es besser. Ein paar posts weiter oben habe ich eine maximal einfache Variante gezeigt. :
Bearbeitet durch User
Im Übrigen, was hat den die Anzahl der RaspPis damit zu tun, wenn auf jedem einzelnen immer nur eine Instanz läuft? Irgendetwas stimmt doch hier nicht…
Bei 25+ Raspis müsste ich das doch wohl 25+ mal, z.B. per SSH-Session machen, oder etwa nicht? :
Bearbeitet durch User
Erstens kann man das automatisieren und zweitens: Ja wie denn sonst? Entweder reihum abfragen oder per cron an einen zentralen Server senden lassen. It's a dirty job, but somebody's got to do it… Edit: Und wenn du's bequem haben willst, dann einfach remote in eine zentrale RRD einspeisen. :
Bearbeitet durch User
Ich habs bequem: Es gibt eine App, die auf den Raspis läuft und sowieso regelmäßig automtaisch aktualisiert wird. Dort bau' ich die Shell-Aufrufe ein. :
Bearbeitet durch User
Easy peasy: https://www.fabfile.org/
Du meinst natürlich einen systemd.timer(5)... ;-) aber wie auch immer, hast Du vollkommen Recht: dazu bedarf es je einer Software auf den 25+ RasPis, im Monitoring-Sprech einen Agent, welche periodisch aufgerufen wird und die Daten irgendwo einliefert -- oder, wenn der Einlieferungspunkt gerade einmal nicht verfügbar sein sollte, die Daten puffert, bis er wieder da ist. So etwas wird häufig als Push-Technologie bezeichnet und bedarf eines höheren initialen Aufwandes, damit einerseits ein zentraler Einlieferungspunkt geschaffen (mit entsprechenden Verarbeitungskapazitäten) wird. Außerdem muß auf den Clients die entsprechende Software ausgerollt und gepflegt werden. Andererseits gibt es natürlich auch Pull-Technologien, die je nach konkretem Anwendungsfall große Vorzüge haben. Wenn es nun nur darum ginge, vereinzelte Meßdaten zu sammeln, würde sich wohl eher eine Pull-Technologie empfehlen, die also nacheinander oder womöglich parallel (da das Netzwerk hier im Zweifel der Flaschenhals ist, böte sich das für Parallelisierung per Multithreading, Async oder Green Threads geradezu an) die Daten ausliest und sie weiterverarbeitet. Ein Nachteil einer Pull-Technologie ist aber, daß die zentrale Sammelinstanz Zugang zu den Maschinen haben muß, was sich heutzutage aber mit einem relativ hohen Sicherheitsniveau über SSH machen läßt. Eine weitere Option wäre eine Mischung aus Push- und Pull-Technologie. Zum Beispiel könnte man das Paket sysstat installieren und konfigurieren, das periodisch die Performance-Counter des Linux-Kernels ausliest und speichert, darunter auch die Daten für alle vorhandenen Dateisysteme. Mit dem Programm sar(1) lassen sich diese standardmäßig unter /var/log/sysstat/ komprimiert gespeicherten Daten in einem tabellarischen Format ausgeben, oder mit dem Hilfsprogramm sadf(1) auch in CSV, JSON, XML, oder dem passenden Format für den Performance Co-Pilot (PCP). Während der System Activity Reporter (sar) dann als Datensammelagent arbeiten würde, würde andererseits nur noch eine zentrale Software benötigt, die die Daten der Hosts holt und verarbeitet. Nebenbei bemerkt gibt es in dem vom TO gewünschten Umfald eine ganze Reihe etablierter Software, vom klassischen Monitoring mit zum Beispiel Nagios oder Icinga bis hin zu modernen Observability-Lösungen, die außer Performancedaten auch noch andere Datenquellen wie System- und Applikationslogs einsammeln und zusammenführen, um den gesamten Systemzustand abzubilden. Solche Systeme sind allerdings meist nicht ganz trivial aufzusetzen und zu nutzen.
Wenn es grafisch aufbereitet sein darf, wie bei Diskspace naheliegend: MRTG. Abfrage per SNMP. :
Bearbeitet durch User
Trotzdem ich bekanntlich ein Freund von etablierten Technologien bin, werden SNMP und ich wohl keine Freunde mehr... :-)
Ach nun ja, was vierzig Jahre gut funktioniert hat, wird ab morgen Vormittag nicht plötzlich schlecht. ;-)
Dabei will er doch nur wissen wie viel Platz noch iss… ;-) Nachsatz: So schnell kann man ja die BS-Bingo Karten gar nicht abstempeln. Was war es, Kloooot oder ShitGPT?
Angehängte Dateien:
:
Bearbeitet durch User
Und Du denkst, das bleibt so? Ich hab da andere Erfahrungen.
Was soll das, bist Du etwa neidisch?
Lies diese ›wall of text‹ noch einmal mit einem etwas anderen Blickwinkel. ;-)
Was hat es dir angetan? :) :
Bearbeitet durch User
Die "Wall of Text" ist IMHO lesenswert, benennt die relevanten Zusammenhänge und liefert Stichworte für weitere Recherchen.
Security, Inkonsistenzen, Performance... SNMP benutze ich höchstens, wenn wirklich überhaupt nichts anderes geht. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
