Raspian - gesamten freien Speicher der SD-Karte anzeigen

[Frank E. (Firma: Q3) (qualidat)]

Ich 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.

[(prx) A. K. (prx)]

df -h / | awk 'NR==2 {print $4}'
      ^Filesystem  ^Zeile    ^Spalte

[(prx) A. K. (prx)]

Alternativ, nach Lektüre von
  man df
kommt man auf
  df --output=avail -h / | tail -n1

[Εrnst B. (ernst)]

>> stat -f -c %a /

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:
>> stat -f -c %a*%S / | bc

[(prx) A. K. (prx)]

Den bc müsste er allerdings nachinstallieren. Heftige Aufgabe. :)

[Frank E. (Firma: Q3) (qualidat)]

Danke! Hab mich für die Variante von Ernst B. entschieden.

[Norbert (der_norbert)]

(prx) A. K. schrieb:
> Den bc müsste er allerdings nachinstallieren. Heftige Aufgabe. :)

stat -f -c "echo \$((%a*%S))" / | bash

[Harald K. (kirnbichler)]

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".

[(prx) A. K. (prx)]

Harald K. schrieb:
> Was bringt das eigentlich?

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.

[Harald K. (kirnbichler)]

(prx) A. K. schrieb:
> Den freien Platz auf dem Root-FS.

OK, dann hatte ich da was missverstanden. Ja, genau das ist die einzig 
sinnvolle Angabe.

[Yalu X. (yalu) (Moderator)]

(prx) A. K. schrieb:
> 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.

Der folgende Satz könnte darauf hindeuten, dass der TE genau das möchte:

Frank E. schrieb:
> Das immerzu mir empfohlene "df -h" liefert statt dessen eine Liste,
> mit der ich im konkreten fall nichts anfangen kann.

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.

Frank E. schrieb:
> Danke! Hab mich für die Variante von Ernst B. entschieden.

Das wiederum lässt vermuten, dass das Root-Filesystem ausreicht.

Falls nicht, sollte der TE seinen Wunsch etwas genauer spezifizieren.

[(prx) A. K. (prx)]

Yalu X. schrieb:
> dass der TE genau das möchte

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.

[Norbert (der_norbert)]

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:

lsblk -bno FSAVAIL /dev/sdb1

Ergebnis in Bytes:

3099308032

[Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche)]

df -h .

[Frank E. (Firma: Q3) (qualidat)]

(prx) A. K. schrieb:
> Yalu X. schrieb:
>> dass der TE genau das möchte
>
> Oder dass er den Schritt von
>   df -h
> zu
>   df -h /
> nicht schaffte. So hatte ich das in Erinnerung an frühere Fragen
> interpretiert.

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.

[Frank E. (Firma: Q3) (qualidat)]

Norbert schrieb:
> (prx) A. K. schrieb:
>> Den bc müsste er allerdings nachinstallieren. Heftige Aufgabe. :)stat -f -c
> "echo \$((%a*%S))" / | bash

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.

[Norbert (der_norbert)]

Frank E. schrieb:
> 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.

Unnötig trifft es besser. Ein paar posts weiter oben habe ich eine 
maximal einfache Variante gezeigt.

[(prx) A. K. (prx)]

Frank E. schrieb:
> Ich wollte gerne EINE Zahl

Die hatte ich geliefert. In 2 Varianten.

[Norbert (der_norbert)]

Frank E. schrieb:
> Nö, nur ziemlich unpraktisch bei dutzenden laufenden Raspis.

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…

[Frank E. (Firma: Q3) (qualidat)]

(prx) A. K. schrieb:

> 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?

[Norbert (der_norbert)]

Frank E. schrieb:
> Bei 25+ Raspis müsste ich das doch wohl 25+ mal, z.B. per SSH-Session
> machen, oder etwa nicht?

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.

[Frank E. (Firma: Q3) (qualidat)]

Norbert schrieb:

> Und wenn du's bequem haben willst, dann einfach remote in eine zentrale
> RRD einspeisen.

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.

[Ein T. (ein_typ)]

Frank E. schrieb:
> Bei 25+ Raspis müsste ich das doch wohl 25+ mal, z.B. per SSH-Session
> machen, oder etwa nicht?

Easy peasy: https://www.fabfile.org/

[Ein T. (ein_typ)]

Norbert schrieb:
> Entweder reihum abfragen oder per cron an einen zentralen Server senden
> lassen.

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.

[(prx) A. K. (prx)]

Ein T. schrieb:
> Nebenbei bemerkt gibt es in dem vom TO gewünschten Umfald eine ganze
> Reihe etablierter Software

Wenn es grafisch aufbereitet sein darf, wie bei Diskspace naheliegend:
MRTG. Abfrage per SNMP.

[Ein T. (ein_typ)]

(prx) A. K. schrieb:
> Wenn es grafisch aufbereitet sein darf, wie bei Diskspace naheliegend:
> MRTG. Abfrage per SNMP.

Trotzdem ich bekanntlich ein Freund von etablierten Technologien bin, 
werden SNMP und ich wohl keine Freunde mehr... :-)

[Norbert (der_norbert)]

Ein T. schrieb:
> Norbert schrieb:
>> Entweder reihum abfragen oder per cron an einen zentralen Server senden
>> lassen.
>
> Du meinst natürlich einen systemd.timer(5)...  ;-)

Ach nun ja, was vierzig Jahre gut funktioniert hat, wird ab morgen 
Vormittag nicht plötzlich schlecht. ;-)

> … Agent … Push-Technologie … Pull-Technologien …
> … Parallelisierung per Multithreading, Async oder Green Threads
> … sysstat … Performance-Counter … CSV, JSON, XML
> … Performance Co-Pilot (PCP)
> … System Activity Reporter (sar)

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?

[Sheeva P. (sheevaplug)]

Norbert schrieb:
> Dabei will er doch nur wissen wie viel Platz noch iss… ;-)

Und Du denkst, das bleibt so? Ich hab da andere Erfahrungen.

> Nachsatz: So schnell kann man ja die BS-Bingo Karten gar nicht
> abstempeln. Was war es, Kloooot oder ShitGPT?

Was soll das, bist Du etwa neidisch?

[Norbert (der_norbert)]

Sheeva P. schrieb:
> Was soll das, bist Du etwa neidisch?

Lies diese ›wall of text‹ noch einmal mit einem etwas anderen 
Blickwinkel. ;-)

[(prx) A. K. (prx)]

Ein T. schrieb:
> Trotzdem ich bekanntlich ein Freund von etablierten Technologien bin,
> werden SNMP und ich wohl keine Freunde mehr... :-)

Was hat es dir angetan? :)

[Sheeva P. (sheevaplug)]

Norbert schrieb:
> Sheeva P. schrieb:
>> Was soll das, bist Du etwa neidisch?
>
> Lies diese ›wall of text‹ noch einmal mit einem etwas anderen
> Blickwinkel. ;-)

Die "Wall of Text" ist IMHO lesenswert, benennt die relevanten 
Zusammenhänge und liefert Stichworte für weitere Recherchen.

[Ein T. (ein_typ)]

(prx) A. K. schrieb:
> Ein T. schrieb:
>> Trotzdem ich bekanntlich ein Freund von etablierten Technologien bin,
>> werden SNMP und ich wohl keine Freunde mehr... :-)
>
> Was hat es dir angetan? :)

Security, Inkonsistenzen, Performance... SNMP benutze ich höchstens, 
wenn wirklich überhaupt nichts anderes geht.