Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #113925 > unrolled thread

Absturz ArchLinux mit Storage=volatile

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-09 12:55 -0800
    Re: Absturz ArchLinux mit Storage=volatile Arno Lutz <invalid@freakmail.de> - 2021-01-09 22:03 +0100
      Re: Absturz ArchLinux mit Storage=volatile Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-01-09 22:58 +0100
        Re: Absturz ArchLinux mit Storage=volatile Arno Lutz <invalid@freakmail.de> - 2021-01-09 23:14 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:16 -0800
        Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:50 +0100
        Re: Absturz ArchLinux mit Storage=volatile Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-01-10 09:11 +0100
      Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:32 +0100
    Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 08:43 +0100
      Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-10 15:47 +0000
        Re: Absturz ArchLinux mit Storage=volatile Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-01-10 18:52 +0100
          Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-11 16:22 +0000
            Re: Absturz ArchLinux mit Storage=volatile Ralph Angenendt <dein.name@strg-alt-entf.org> - 2021-01-11 17:08 +0000
              Re: Absturz ArchLinux mit Storage=volatile "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-01-11 18:48 +0000
            Re: Absturz ArchLinux mit Storage=volatile Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-01-11 21:14 +0100
      Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:35 -0800
        Re: Absturz ArchLinux mit Storage=volatile Christian Garbs <mitch@cgarbs.de> - 2021-01-11 20:07 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 11:50 -0800
            Re: Absturz ArchLinux mit Storage=volatile Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-01-13 22:40 +0100
              Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-13 15:21 -0800
    Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-10 11:28 +0100
      Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-11 09:11 -0800
        Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-14 16:47 +0100
          Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-15 13:21 -0800
            Re: Absturz ArchLinux mit Storage=volatile Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2021-01-18 18:43 +0100
              Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-01-18 15:18 -0800
              Re: Absturz ArchLinux mit Storage=volatile Christian Garbs <mitch@cgarbs.de> - 2021-01-19 20:57 +0100
    Re: Absturz ArchLinux mit Storage=volatile Joerg <news@analogconsultants.com> - 2021-02-13 12:27 -0800

Page 1 of 2  [1] 2  Next page →

#113925 — Absturz ArchLinux mit Storage=volatile

Kleiner 800MHz ARM von Marvell, ArchLinux drauf.

[joerg@alarm ~]$ cat /etc/os-release
NAME="Arch Linux ARM"
PRETTY_NAME="Arch Linux ARM"
ID=archarm
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://archlinuxarm.org/"
DOCUMENTATION_URL="https://archlinuxarm.org/wiki"
SUPPORT_URL="https://archlinuxarm.org/forum"
BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues"

Um dessen USB Stick nicht durch Logging zu verschleissen, habe ich in 
/etc/systemd/journald.conf.d eine simple Dafei "usbstick.conf" gesetzt 
mit folgendem Inhalt:

# [Journal]
Storage=volatile
RuntimeMaxUse=10M [Journal]

Damit stuerzt das Dingen alle 2-3 Wochen ab. Kein ssh mehr, kein ping 
mehr, nix. Dann muss ich den Keller fuer einen Power Cycle. Ok, 
Treppenlaufen haelt auch fit, aber es nervt, wenn das mitten bei der 
Arbeit passiert. Natuerlich gibt es damit nach dem Absturz kein Log.

Also habe ich die letzten beiden Zeilen mal auskommentiert, um ein Log 
zu bekommen und den Uebeltaeter zu stellen. Nur ... stuerzt das 
Kaestchen dann nicht mehr ab ... <kopfkratz>.

Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
die 10M voll sind und das Log anfaengt zu rollen?

Andere Frage: Das OS belegt 2GB auf einem 32GB Stick und ansonsten wird 
hoechstens mal 5-10GB an Backup draufgeschrieben und das sehr selten, 
der Rest bleibt leer. Waere der Verschleiss durch staendiges Logging mit 
so einem grossen Stick vernachlaessigbar, sodass ich systemd Logging 
einfach non-volatile laufen lassen koennte?

Sonst gaebe es vielleicht noch die Methode, jeden Sonntag per cron Job 
einen Reset machen zu lassen, denn das Dingen dient hier nur als NAS. 
Waere aber unspochtlich und wohl auch fuer einen Linux-Anfaenger nicht 
die feine englische.

Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
fuer den Job locker reicht. ArchLinux und die wenigen noetigen Programme 
belegen keine 40MB.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [next] | [standalone]

#113926

Am 09.01.21 um 21:55 schrieb Joerg:
> Um dessen USB Stick nicht durch Logging zu verschleissen, habe ich in
> /etc/systemd/journald.conf.d eine simple Dafei "usbstick.conf" gesetzt
> mit folgendem Inhalt:
> 
> # [Journal]
> Storage=volatile
> RuntimeMaxUse=10M [Journal]
> 
> Damit stuerzt das Dingen alle 2-3 Wochen ab.

ich hab nen Raspberry Pi 2B. Seit~ 5Jahren.
Immer noch erste(1!) Karte mit 4GB drin.
Läuft 24/7/365 mit fhem.
Da wird ohne Ende geloggt.
Mach ich mir Gedanken wegen der Karte?
Nein.
zur Not hätte ich ein Image falls die Karte mal sterben sollte.

Wie lange denkst du, bis ein USB-Stick verschlissen ist und was dann ein 
neuer kosten würde?

Gruß
Arno

[toc] | [prev] | [next] | [standalone]

#113928

Thus spoke Arno Lutz:
> Am 09.01.21 um 21:55 schrieb Joerg:
>
>> Um dessen USB Stick nicht durch Logging zu verschleissen,
>> habe ich in /etc/systemd/journald.conf.d eine simple Dafei
>> "usbstick.conf" gesetzt mit folgendem Inhalt:
>>
>> # [Journal]
>> Storage=volatile
>> RuntimeMaxUse=10M [Journal]
>>
>> Damit stuerzt das Dingen alle 2-3 Wochen ab.
>
> ich hab nen Raspberry Pi 2B. Seit~ 5Jahren.
> Immer noch erste(1!) Karte mit 4GB drin.
> Läuft 24/7/365 mit fhem.
> Da wird ohne Ende geloggt.
> Mach ich mir Gedanken wegen der Karte?
> Nein.
> zur Not hätte ich ein Image falls die Karte mal sterben
> sollte. 
> [...]

Ich halte dagegen: Raspberry Pi 1B, mit SD-Karten (IIRC 
SanDisk), Standard-Logging und sehr moderatem Schreiben in eine 
MySQL-Datenbank sowie Schreiben in RRD-Datenbanken (Cacti). 
Länger als ca. 1-1,5 Jahre haben die Karten nicht gehalten. Nach 
der zweiten oder dritten gehimmelten Karten hatte ich die Nase 
voll und das Konstrukt gegen einen RasPi 3B mit USB-SSD ersetzt. 
Seitdem ist Ruhe.


Tschüs,

Sebastian

[toc] | [prev] | [next] | [standalone]

#113929

Am 09.01.21 um 22:58 schrieb Sebastian Suchanek:
>> ich hab nen Raspberry Pi 2B. Seit~ 5Jahren.
>> Immer noch erste(1!) Karte mit 4GB drin.
>> Läuft 24/7/365 mit fhem.
>> Da wird ohne Ende geloggt.
>> Mach ich mir Gedanken wegen der Karte?
>> Nein.
>> zur Not hätte ich ein Image falls die Karte mal sterben
>> sollte.
>> [...]
> Ich halte dagegen: Raspberry Pi 1B, mit SD-Karten (IIRC
> SanDisk), Standard-Logging und sehr moderatem Schreiben in eine
> MySQL-Datenbank sowie Schreiben in RRD-Datenbanken (Cacti).
> Länger als ca. 1-1,5 Jahre haben die Karten nicht gehalten. Nach
> der zweiten oder dritten gehimmelten Karten hatte ich die Nase
> voll und das Konstrukt gegen einen RasPi 3B mit USB-SSD ersetzt.
> Seitdem ist Ruhe.

ganz ehrlich?
Ich wundere mich auch, das die so lange hält.
Kartentyp könnt ich jetzt nicht benennen, war alles mal ein bundle.
Offensichtlich nicht die schlechteste Qualität und Wahl.
Trotzdem, Image ist vorhanden.
Logdateien sind mir nicht sooo wichtig.
Das System wie es ist zählt für mich. Einstellungen etc von und in fhem.
Stirbt die Karte, gibts ne neue.
Immer noch sparsamer als SSD.


Gruß
Arno

[toc] | [prev] | [next] | [standalone]

#113966

On 1/9/21 2:14 PM, Arno Lutz wrote:
> Am 09.01.21 um 22:58 schrieb Sebastian Suchanek:
>>> ich hab nen Raspberry Pi 2B. Seit~ 5Jahren.
>>> Immer noch erste(1!) Karte mit 4GB drin.
>>> Läuft 24/7/365 mit fhem.
>>> Da wird ohne Ende geloggt.
>>> Mach ich mir Gedanken wegen der Karte?
>>> Nein.
>>> zur Not hätte ich ein Image falls die Karte mal sterben
>>> sollte.
>>> [...]
>> Ich halte dagegen: Raspberry Pi 1B, mit SD-Karten (IIRC
>> SanDisk), Standard-Logging und sehr moderatem Schreiben in eine
>> MySQL-Datenbank sowie Schreiben in RRD-Datenbanken (Cacti).
>> Länger als ca. 1-1,5 Jahre haben die Karten nicht gehalten. Nach
>> der zweiten oder dritten gehimmelten Karten hatte ich die Nase
>> voll und das Konstrukt gegen einen RasPi 3B mit USB-SSD ersetzt.
>> Seitdem ist Ruhe.
> 
> ganz ehrlich?
> Ich wundere mich auch, das die so lange hält.
> Kartentyp könnt ich jetzt nicht benennen, war alles mal ein bundle.
> Offensichtlich nicht die schlechteste Qualität und Wahl.


Ist es bei mir auch, der USB Stick ist ein Sandisk Cruzer, gute Qualitaet.


> Trotzdem, Image ist vorhanden.
> Logdateien sind mir nicht sooo wichtig.
> Das System wie es ist zählt für mich. Einstellungen etc von und in fhem.
> Stirbt die Karte, gibts ne neue.
> Immer noch sparsamer als SSD.
> 

Mir waere lieber, wenn das alles "ewig" haelt. Denn sowas geht nach 
Murphy's Law kaputt, wenn gerade die Herzallerliebste drauf zugreifen 
muss und ich ganztaegig auf Radtour bin oder so.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#113936

Am 09.01.21 um 22:58 schrieb Sebastian Suchanek:
> Ich halte dagegen: Raspberry Pi 1B, mit SD-Karten (IIRC
> SanDisk), Standard-Logging und sehr moderatem Schreiben in eine
> MySQL-Datenbank sowie Schreiben in RRD-Datenbanken (Cacti).
         ^^^^^^^^^
Komplett andere Tüte. Mit Datenbanken bekommt man fast jeden 
Flashspeicher kurz. Selbst deren interne Reorg-Prozesse schreiben 
üblicherweise schon ständig irgendwas rum. Und das Transaktions-Log 
nebst der häufigen fsyncs sorgt dann noch für eine ordentliche 
Write-Amplification.

> Länger als ca. 1-1,5 Jahre haben die Karten nicht gehalten. Nach
> der zweiten oder dritten gehimmelten Karten hatte ich die Nase
> voll und das Konstrukt gegen einen RasPi 3B mit USB-SSD ersetzt.
> Seitdem ist Ruhe.

SSDs sind natürlich härter im Nehmen als diese Billig-USB-Sticks und vor 
allem meistens größer. Aber beliebig lange überleben die das auch nicht. 
Mit dem Transaktionslog einer gut genutzten DB bekommt man eine 
Consumer-SSD auch in ein paar Monaten kurz.


Marcel

[toc] | [prev] | [next] | [standalone]

#113937

Am 09.01.21 um 22:58 schrieb Sebastian Suchanek:

> Ich halte dagegen: Raspberry Pi 1B, mit SD-Karten (IIRC
> SanDisk), Standard-Logging und sehr moderatem Schreiben in eine
> MySQL-Datenbank sowie Schreiben in RRD-Datenbanken (Cacti).
> Länger als ca. 1-1,5 Jahre haben die Karten nicht gehalten. Nach
> der zweiten oder dritten gehimmelten Karten hatte ich die Nase
> voll und das Konstrukt gegen einen RasPi 3B mit USB-SSD ersetzt.

Mein raspberri pi Kombinationen
enthält immer eine HD-Festplatte.

( Ausnahme wenn raspberry pi transportiert wird,
   wird statt Festplatte USB-stick verwendet. )

Eigene (Quell)Programme und Daten + kopierte Daten
sind auf Festplatte.

SD-Karten sind bist auf wenige Änderungen
( z.B. hostname ) identisch

Hermann
    erwägend, alles in /etc/fstab ( außer tmpfs )
    auch noch auf noatime zu setzen.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#113934

Am 09.01.21 um 22:03 schrieb Arno Lutz:
> ich hab nen Raspberry Pi 2B. Seit~ 5Jahren.
> Immer noch erste(1!) Karte mit 4GB drin.
> Läuft 24/7/365 mit fhem.
> Da wird ohne Ende geloggt.

Da hast Du Glück. Nach meiner Erfahrung frisst so ein Pi etwa alle 5 
Jahre eine Karte. Ist jetzt kein Invest, aber der Ausfall nervt.
Und ältere, kleinere Karten vertragen zuweilen mehr Schreibzyklen.


Marcel

[toc] | [prev] | [next] | [standalone]

#113935

Am 09.01.21 um 21:55 schrieb Joerg:
> # [Journal]
> Storage=volatile
> RuntimeMaxUse=10M [Journal]
> 
> Damit stuerzt das Dingen alle 2-3 Wochen ab. Kein ssh mehr, kein ping 
> mehr, nix. Dann muss ich den Keller fuer einen Power Cycle. Ok, 
> Treppenlaufen haelt auch fit, aber es nervt, wenn das mitten bei der 
> Arbeit passiert. Natuerlich gibt es damit nach dem Absturz kein Log.
> 
> Also habe ich die letzten beiden Zeilen mal auskommentiert, um ein Log 
> zu bekommen und den Uebeltaeter zu stellen. Nur ... stuerzt das 
> Kaestchen dann nicht mehr ab ... <kopfkratz>.

Erstelle doch parallel mal das gute alte syslog, so wie bei 
Debian/Ubuntu. Das schreibt auch weniger als das komische Binärformat.

> Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
> die 10M voll sind und das Log anfaengt zu rollen?

Falls es damit zu tun hat, stelle die Größe halt man auf 100k, dann 
weißt Du es sehr schnell. Vielleicht hilft das syslog dann auch bei der 
Diagnose.


> Andere Frage: Das OS belegt 2GB auf einem 32GB Stick und ansonsten wird 
> hoechstens mal 5-10GB an Backup draufgeschrieben und das sehr selten, 
> der Rest bleibt leer.

Der Rest bleibt nicht leer. Dateisysteme schreiben nicht immer an 
dieselbe Stelle. Und Trim funktioniert bei USB-Sticks manchmal mal bei 
günstiger Sternenkonstellation.
Wenn Du wirklich sicher stellen willst, dass der Stick viel Spielraum 
hat, darf er /niemals/ vollständig partitioniert worden sein. Das Drops 
ist mutmaßlich schon gelutscht.

> Waere der Verschleiss durch staendiges Logging mit 
> so einem grossen Stick vernachlaessigbar, sodass ich systemd Logging 
> einfach non-volatile laufen lassen koennte?

Mutmaßlich ja. Je nach Umfang des Loggings kann das schon so manche 
Jahre überleben. 10MB in 2 Wochen (sofern das stimmt) wäre wenig. 
Allerdings gibt es bei Logs eine erhebliche Write-Amplification. Ich 
würde mit >12k pro Logeintrag rechnen. Ein 4k Block fürs Log und 2 fürs 
Dateisystem-Journal (open, close).

> Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
> fuer den Job locker reicht. ArchLinux und die wenigen noetigen Programme 
> belegen keine 40MB.

Hast Du swap an? Manche Systeme lagern schon mal auf Vorrat aus, auch 
wenn es noch nicht eng wird.


Marcel

[toc] | [prev] | [next] | [standalone]

#113943

Marcel Mueller schrieb am 10/1/2021 08:43:
>
> Der Rest bleibt nicht leer. Dateisysteme schreiben nicht immer an 
> dieselbe Stelle. Und Trim funktioniert bei USB-Sticks manchmal mal bei 
> günstiger Sternenkonstellation.
> Wenn Du wirklich sicher stellen willst, dass der Stick viel Spielraum 
> hat, darf er /niemals/ vollständig partitioniert worden sein. Das Drops 
> ist mutmaßlich schon gelutscht.

Und wenn man bei neuen USB-Sticks und SD-Karten zur Prüfung vor
Fälschungen F3 (oder h2testw.exe) drüber laufen lässt und damit
vollständig beschreibt, hat man wohl von Anfang an verloren :-( 
Werde ich zukünftig eher bleiben lassen.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#113950

Am 10.01.21 um 16:47 schrieb Gerald E:scher:
> Marcel Mueller schrieb am 10/1/2021 08:43:
>> Wenn Du wirklich sicher stellen willst, dass der Stick viel Spielraum
>> hat, darf er /niemals/ vollständig partitioniert worden sein. Das Drops
>> ist mutmaßlich schon gelutscht.
> 
> Und wenn man bei neuen USB-Sticks und SD-Karten zur Prüfung vor
> Fälschungen F3 (oder h2testw.exe) drüber laufen lässt und damit
> vollständig beschreibt, hat man wohl von Anfang an verloren :-(
> Werde ich zukünftig eher bleiben lassen.

Manche Sticks werten ein Schreiben von komplett Nullen als Trim-Ersatz.


Marcel

[toc] | [prev] | [next] | [standalone]

#113962

Marcel Mueller schrieb am 10/1/2021 18:52:

> Am 10.01.21 um 16:47 schrieb Gerald E:scher:
>> 
>> Und wenn man bei neuen USB-Sticks und SD-Karten zur Prüfung vor
>> Fälschungen F3 (oder h2testw.exe) drüber laufen lässt und damit
>> vollständig beschreibt, hat man wohl von Anfang an verloren :-(
>> Werde ich zukünftig eher bleiben lassen.
>
> Manche Sticks werten ein Schreiben von komplett Nullen als Trim-Ersatz.

Ich habe mit den microSD-Karten (Kingston Industrial, Transcend) in zwei
Raspberry Pis mit dd rumprobiert.
Nullen
$ dd if=/dev/zero of=null.bin bs=1M count=100 status=progress oflag=sync
werden etwas schneller geschrieben als Zufallszahlen. 
$ dd if=/dev/urandom of=null.bin bs=1M count=100 status=progress \
  oflag=sync

Bedeutet das, dass die beiden microSD-Karten mit Nullen vollgeschriebene
Blöcke anders behandeln und TRIMen?

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#113964

Well, Gerald E:scher <Spamer@fahr-zur-Hoelle.org> wrote:
> Ich habe mit den microSD-Karten (Kingston Industrial, Transcend) in zwei
> Raspberry Pis mit dd rumprobiert.
> Nullen
> $ dd if=/dev/zero of=null.bin bs=1M count=100 status=progress oflag=sync
> werden etwas schneller geschrieben als Zufallszahlen. 
> $ dd if=/dev/urandom of=null.bin bs=1M count=100 status=progress \
>   oflag=sync
>
> Bedeutet das, dass die beiden microSD-Karten mit Nullen vollgeschriebene
> Blöcke anders behandeln und TRIMen?

Meine Festplatte im Server auch:

| range@teatime:~/tmp$ dd if=/dev/zero of=null.bin bs=1M count=100 \ 
| status=progress oflag=sync
| 104857600 bytes (105 MB, 100 MiB) copied, 10.7001 s, 9.8 MB/s
| range@teatime:~/tmp$ dd if=/dev/urandom of=null.bin bs=1M count=100 \  
| status=progress oflag=sync
| 104857600 bytes (105 MB, 100 MiB) copied, 23.0655 s, 4.5 MB/s

Ich tippe eher auf /dev/urandom, wenn man das sync mal weglässt:

| range@teatime:~/tmp$ dd if=/dev/zero of=null.bin bs=1M count=100 \  
| status=progress
| 104857600 bytes (105 MB, 100 MiB) copied, 0.220644 s, 475 MB/s
| range@teatime:~/tmp$ dd if=/dev/urandom of=null.bin bs=1M count=100 \  
| status=progress
| 104857600 bytes (105 MB, 100 MiB) copied, 5.03002 s, 20.8 MB/s
| 104857600 bytes (105 MB, 100 MiB) copied, 5.07905 s, 20.6 MB/s


Ralph
-- 
Übervaterlandverräter und Mutterkornmblumenblau

[toc] | [prev] | [next] | [standalone]

#113969

Ralph Angenendt schrieb am 11/1/2021 18:08:

> Well, Gerald E:scher <Spamer@fahr-zur-Hoelle.org> wrote:
>> Ich habe mit den microSD-Karten (Kingston Industrial, Transcend) in zwei
>> Raspberry Pis mit dd rumprobiert.
>> Nullen
>> $ dd if=/dev/zero of=null.bin bs=1M count=100 status=progress oflag=sync
>> werden etwas schneller geschrieben als Zufallszahlen. 
>> $ dd if=/dev/urandom of=null.bin bs=1M count=100 status=progress \
>>   oflag=sync
>>
>> Bedeutet das, dass die beiden microSD-Karten mit Nullen vollgeschriebene
>> Blöcke anders behandeln und TRIMen?
>
> Meine Festplatte im Server auch:
>
> | range@teatime:~/tmp$ dd if=/dev/zero of=null.bin bs=1M count=100 \ 
> | status=progress oflag=sync
> | 104857600 bytes (105 MB, 100 MiB) copied, 10.7001 s, 9.8 MB/s
> | range@teatime:~/tmp$ dd if=/dev/urandom of=null.bin bs=1M count=100 \  
> | status=progress oflag=sync
> | 104857600 bytes (105 MB, 100 MiB) copied, 23.0655 s, 4.5 MB/s
>
> Ich tippe eher auf /dev/urandom, wenn man das sync mal weglässt:

Danke, ja. Bei meinem vermutlich langsameren Server (Intel Core2 Quad)
ist bei dd auf rotierende Platte /dev/zero schneller als /dev/urandom,
egal ob mit oder ohne sync. /dev/urandom wird bei den Raspberrys noch
langsamer sein.
Das Messverfahren taugt wegen zu langsamem /dev/urandom demnach nicht.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#113977

Hallo Gerald,

Du schriebst am 11 Jan 2021 16:22:56 GMT:

> Ich habe mit den microSD-Karten (Kingston Industrial, Transcend) in zwei
> Raspberry Pis mit dd rumprobiert.
> Nullen
...
> werden etwas schneller geschrieben als Zufallszahlen. 
...
> Bedeutet das, dass die beiden microSD-Karten mit Nullen vollgeschriebene
> Blöcke anders behandeln und TRIMen?

Es _könnte_ so sein - zum wirklich durchgängigen Schreiben von 0-Bytes muß
der Flash-Controller nicht die dort schon stehenden Daten löschen, weil
alle Bits auf 0 gesetzt werden, was immer geht. Ein einzelnes Bit (oder
eine beliebige Kombinstion) auf 1 setzen, wenn dort eine 0 steht, geht
prinzipiell bzw. konstruktionsbedingt nicht, dafür muß immer eine ganze
Seite eines Flash-Chips gelöst werden ("Erase unit" o.ä.). Auch wenn das
das einzige 1-Bit auf der ganzen Seite ist und ungünstigerweise dort schon
0 steht...
Aber eher sind die Controller nicht "schlau" genug, einen solchen Fall zu
erkennen, haben wohl auch nicht genug Speicher dafür, und machen das
genauso wie jeden anderen Schreibvorgang. Dann kommt der
Geschwindigkeitsunterschied eher von der Quelle - auch Pseudozufallszahlen
müssen berechnet werden, 0-Bytes kann der Prozessor "aus dem Ärmel (einem
extra Register) schütteln".

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#113967

On 1/9/21 11:43 PM, Marcel Mueller wrote:
> Am 09.01.21 um 21:55 schrieb Joerg:
>> # [Journal]
>> Storage=volatile
>> RuntimeMaxUse=10M [Journal]
>>
>> Damit stuerzt das Dingen alle 2-3 Wochen ab. Kein ssh mehr, kein ping 
>> mehr, nix. Dann muss ich den Keller fuer einen Power Cycle. Ok, 
>> Treppenlaufen haelt auch fit, aber es nervt, wenn das mitten bei der 
>> Arbeit passiert. Natuerlich gibt es damit nach dem Absturz kein Log.
>>
>> Also habe ich die letzten beiden Zeilen mal auskommentiert, um ein Log 
>> zu bekommen und den Uebeltaeter zu stellen. Nur ... stuerzt das 
>> Kaestchen dann nicht mehr ab ... <kopfkratz>.
> 
> Erstelle doch parallel mal das gute alte syslog, so wie bei 
> Debian/Ubuntu. Das schreibt auch weniger als das komische Binärformat.
> 

Muss ich mal sehen, wie man das macht.


>> Weiss jemand, wo ich wuehlen koennte? Koennte irgendwas anecken, wenn 
>> die 10M voll sind und das Log anfaengt zu rollen?
> 
> Falls es damit zu tun hat, stelle die Größe halt man auf 100k, dann 
> weißt Du es sehr schnell. Vielleicht hilft das syslog dann auch bei der 
> Diagnose.
> 

Danke, guter Tipp. Ich habe das mal auf 1MB gesetzt. 100k ist was knapp 
und ich moechte keinen Brick draus machen. Wenn es jetzt bis Ende der 
Woche abstuerzt, liegt es wohl am Log.

> 
>> Andere Frage: Das OS belegt 2GB auf einem 32GB Stick und ansonsten 
>> wird hoechstens mal 5-10GB an Backup draufgeschrieben und das sehr 
>> selten, der Rest bleibt leer.
> 
> Der Rest bleibt nicht leer. Dateisysteme schreiben nicht immer an 
> dieselbe Stelle. Und Trim funktioniert bei USB-Sticks manchmal mal bei 
> günstiger Sternenkonstellation.
> Wenn Du wirklich sicher stellen willst, dass der Stick viel Spielraum 
> hat, darf er /niemals/ vollständig partitioniert worden sein. Das Drops 
> ist mutmaßlich schon gelutscht.
> 

Partitioniert habe ich den nie, aber auf ext formatiert.


>> Waere der Verschleiss durch staendiges Logging mit so einem grossen 
>> Stick vernachlaessigbar, sodass ich systemd Logging einfach 
>> non-volatile laufen lassen koennte?
> 
> Mutmaßlich ja. Je nach Umfang des Loggings kann das schon so manche 
> Jahre überleben. 10MB in 2 Wochen (sofern das stimmt) wäre wenig. 
> Allerdings gibt es bei Logs eine erhebliche Write-Amplification. Ich 
> würde mit >12k pro Logeintrag rechnen. Ein 4k Block fürs Log und 2 fürs 
> Dateisystem-Journal (open, close).
> 

Auf dieses NAS wird nur selten zugegriffen, vielleicht ist es deshalb so 
"wenig". 12k pro Eintrag ist aber schon uebel.


>> Erwaehnen sollte ich noch, dass dieses NAS nur 128MB RAM hat, was aber 
>> fuer den Job locker reicht. ArchLinux und die wenigen noetigen 
>> Programme belegen keine 40MB.
> 
> Hast Du swap an? Manche Systeme lagern schon mal auf Vorrat aus, auch 
> wenn es noch nicht eng wird.
> 

Swap ist aus und es gibt keinen Swap Bereich. Allerdings ist der Buffer 
und Cache Bereich hoch. Koennte es daran liegen?

[joerg@alarm ~]$ free -h
               total        used        free      shared  buff/cache 
available
Mem:          117Mi        33Mi       6.0Mi       0.0Ki        77Mi 
   77Mi
Swap:            0B          0B          0B


Dieses NAS muss nicht schnell sein. Sollte ich den Cache Bereich auf 
50MB oder so heruntersetzen oder wird das bei ArchLinux dynamisch angepasst?

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#113974

Mahlzeit!

Joerg <news@analogconsultants.com> wrote:

> Swap ist aus und es gibt keinen Swap Bereich. Allerdings ist der Buffer 
> und Cache Bereich hoch. Koennte es daran liegen?
> 
> [joerg@alarm ~]$ free -h
>               total        used        free      shared  buff/cache 
> available
> Mem:          117Mi        33Mi       6.0Mi       0.0Ki        77Mi 
>   77Mi
> Swap:            0B          0B          0B
> 
> 
> Dieses NAS muss nicht schnell sein. Sollte ich den Cache Bereich auf
> 50MB oder so heruntersetzen oder wird das bei ArchLinux dynamisch
> angepasst?

Das ist dynamisch, da musst Du nichts konfigurieren: Buffers und
Caches werden automatisch verworfen, wenn ein Prozess mehr Speicher
braucht, als aktuell "free" ist.

Das ist bei allen Linuxen so.


(Es gibt deswegen öfter Leute, die sich beschweren, dass Linux so viel
 Speicher frisst, weil nur ganz wenig "Free" ist und "Buffer/Cache"
 das ganze RAM belegt.  Darauf gibt es dann Antworten wie "Du hast den
 Speicher bezahlt, freu Dich doch, wenn er benutzt wird" und "wenn der
 Speicher nicht benutzt werden soll, bau den Riegel wieder aus".
 Leicht frech, aber in der Sache richtig ;-)

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
If u c4n r34d this u r34lly n33d t0 g37 l41d

[toc] | [prev] | [next] | [standalone]

#113976

On 1/11/21 11:07 AM, Christian Garbs wrote:
> Mahlzeit!
> 
> Joerg <news@analogconsultants.com> wrote:
> 
>> Swap ist aus und es gibt keinen Swap Bereich. Allerdings ist der Buffer
>> und Cache Bereich hoch. Koennte es daran liegen?
>>
>> [joerg@alarm ~]$ free -h
>>                total        used        free      shared  buff/cache
>> available
>> Mem:          117Mi        33Mi       6.0Mi       0.0Ki        77Mi
>>    77Mi
>> Swap:            0B          0B          0B
>>
>>
>> Dieses NAS muss nicht schnell sein. Sollte ich den Cache Bereich auf
>> 50MB oder so heruntersetzen oder wird das bei ArchLinux dynamisch
>> angepasst?
> 
> Das ist dynamisch, da musst Du nichts konfigurieren: Buffers und
> Caches werden automatisch verworfen, wenn ein Prozess mehr Speicher
> braucht, als aktuell "free" ist.
> 
> Das ist bei allen Linuxen so.
> 

Danke, wusste ich noch nicht, hatte es mir aber gedacht und mir bisher 
nie Sorgen drum gemacht.

> 
> (Es gibt deswegen öfter Leute, die sich beschweren, dass Linux so viel
>   Speicher frisst, weil nur ganz wenig "Free" ist und "Buffer/Cache"
>   das ganze RAM belegt.  Darauf gibt es dann Antworten wie "Du hast den
>   Speicher bezahlt, freu Dich doch, wenn er benutzt wird" und "wenn der
>   Speicher nicht benutzt werden soll, bau den Riegel wieder aus".
>   Leicht frech, aber in der Sache richtig ;-)
> 

Oder die alte Regel bei uC-Programmierern, dass sie erst dann aufhoeren, 
wenn das EEPROM zu mindestens 99% voll ist :-)

<tief duck>

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#114007

Hallo Joerg,

Du schriebst am Mon, 11 Jan 2021 11:50:38 -0800:

> Oder die alte Regel bei uC-Programmierern, dass sie erst dann aufhoeren, 
> wenn das EEPROM zu mindestens 99% voll ist :-)
> 
> <tief duck>

Nicht tief genug.
Du beschuldigst hier die falschen, die nichts dafür können, daß sie die
Featuritis der Markentiere immer weiter antreibt, mehr in den verfügbaren
Platz zu packen und das nur dadurch begrenzen können, daß sie dafür den
nächstgrößeren und damit -teureren Prozessor oder Speicherausbau oder
ähnliches brauchen.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#114009

On 1/13/21 1:40 PM, Sieghard Schicktanz wrote:
> Hallo Joerg,
> 
> Du schriebst am Mon, 11 Jan 2021 11:50:38 -0800:
> 
>> Oder die alte Regel bei uC-Programmierern, dass sie erst dann aufhoeren,
>> wenn das EEPROM zu mindestens 99% voll ist :-)
>>
>> <tief duck>
> 
> Nicht tief genug.
> Du beschuldigst hier die falschen, ...


Smiley beachten ...


>                              ... die nichts dafür können, daß sie die
> Featuritis der Markentiere immer weiter antreibt, mehr in den verfügbaren
> Platz zu packen und das nur dadurch begrenzen können, daß sie dafür den
> nächstgrößeren und damit -teureren Prozessor oder Speicherausbau oder
> ähnliches brauchen.
> 

Das darf ich aber auch nicht sagen, denn meine erste Exkursion in die 
Welt der Markentier fuehrte zur Hochzeit und wir sind immer noch 
verheiratet, was auch so bleiben soll :-)

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web