[Lookbehind]

Einfach nur ein klassisches NAS? Du hast keine 12 GB große SQL-Datenbank mit 1250 Querrys pro Minute da drauf liegen? Dann leg einfach dein LVM an und mach dir keinen zu großen Kopf. SO langsam ist LVM nun auch wieder nicht.

[Uripura]

Nee, es sind nur alle meine eigenen Dateien die man so klassischerweise hat, also Dokumente, Bilder, Musik und Videos.

[Lookbehind]

Nee, es sind nur alle meine eigenen Dateien die man so klassischerweise hat, also Dokumente, Bilder, Musik und Videos.

Dann merkst du den Performance-Unterschied nicht. Der ist sicher messbar, aber nicht spürbar.

[Uripura]

Dann merkst du den Performance-Unterschied nicht. Der ist sicher messbar, aber nicht spürbar.

Ich glaube auch nicht, dass es einen großen Unterschied macht.

Nur wenn man es auf die Spitze treibt kommt es doch bestimmt zur starken Fragmentierung.
Gibt es wirklich keine Möglichkeit?

Naja, aber so schlimm ist es wie gesagt wohl nicht.

Dann bleibt mir noch eine Frage:
Ich habe vor mir ein verschlüsseltes RAID5 einzurichten.
In dem Wiki steht, dass man um das RAID5 optimal nutzen zu können man beim Formatieren von dem Dateisystem eine Stripe und Stride width einstellt die abhängig von der Chunk Size von dem RAID sind.
Da Frage ich mich aber überhaupt ob diese Einstellungen die ich ganz oben auf Dateisystemebene mache auch ganz unten auf der RAID-Ebene ankommen.
Ich kann mir vorstellen, dass das dann nach unten hin "wegabstrahiert" wird.

Das geplante Layout wird so aussehen:

+---------------------++---------------------------------++--------+
|                     ||                                 ||        |
| /dev/mapper/daten1  ||     /dev/mapper/daten2          ||  FREI  |
|                     ||                                 ||        |
+---------------------++---------------------------------++--------+
+------------------------------------------------------------------+
|                                LVM                               |
|                       /dev/mapper/lvm-pool                       |
|                                                                  |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|                       LUKS Verschlüsselung                       |
|                            /dev/md1                              |
|                                                                  |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|                              RAID5                               |
|                            /dev/md1                              |
|                                                                  |
+------------------------------------------------------------------+
+--------------------+ +--------------------+ +--------------------+
|                    | |                    | |                    |
|      /dev/sda1     | |    /dev/sdb1       | |     /dev/sdc1      |
|                    | |                    | |                    |
+--------------------+ +--------------------+ +--------------------+

[Lookbehind]

Wow! Hast du ein Tooling für die Grafik? Wenn ja, welches, wenn nein, wie lange hats gedauert?

Du kannst die Chunk-Size beim anlegen des Dateisystems angeben, und die sollte dann idealerweise zu den Stripes im RAID passen. Da wird nix nach unten durch propagiert, sondern du musst das selber anpassen. Wobei ich nicht weiß, in wie weit ein COW-System wie LVM einem da einen Strich durch die Rechnung macht.

Faktisch auch da: Mach dir keinen zu großen Kopf. Ich hab bisher immer einfach alles auf Default gelassen und nie Probleme bekommen. Derartiges Feintuning wird erst interessant, wenn du wirklich das absolut allerletzte aus deinem System raus quetschen möchtest. ... wobei ich dann vielleicht eher einen NVMe-Cache empfehlen würde.

Edith meint, dass bei dir wahrscheinlich ohnehin der Verschlüsselungs-Layer zum Flaschenhals wird. Trotz AES in Hardware. ... Wobei "Flaschenhals" hier wohl immernoch mehr als schnell genug sein dürfte.

[Uripura]

Wow! Hast du ein Tooling für die Grafik? Wenn ja, welches, wenn nein, wie lange hats gedauert?

Du kannst die Chunk-Size beim anlegen des Dateisystems angeben, und die sollte dann idealerweise zu den Stripes im RAID passen. Da wird nix nach unten durch propagiert, sondern du musst das selber anpassen. Wobei ich nicht weiß, in wie weit ein COW-System wie LVM einem da einen Strich durch die Rechnung macht.

Faktisch auch da: Mach dir keinen zu großen Kopf. Ich hab bisher immer einfach alles auf Default gelassen und nie Probleme bekommen. Derartiges Feintuning wird erst interessant, wenn du wirklich das absolut allerletzte aus deinem System raus quetschen möchtest. ... wobei ich dann vielleicht eher einen NVMe-Cache empfehlen würde.

Edith meint, dass bei dir wahrscheinlich ohnehin der Verschlüsselungs-Layer zum Flaschenhals wird. Trotz AES in Hardware. ... Wobei "Flaschenhals" hier wohl immernoch mehr als schnell genug sein dürfte.

Das habe ich von Hand gemacht, dafür brauchte ich ungefähr 10 Minuten.
Ging schneller und auch schöner als es aufzuschreiben oder zu malen.
Wenn Du ein Programm kennst mit dem das geht bin ich ganz Ohr.

Das mit der Chunk Size beim RAID und den Werten für ext4 habe ich schon alles, es geht mir nur darum, dass das ganze auch unten ankommt.
Und weil der NAS selber auch nicht so viel Leistung hat möchte ich auch das maximale aus dem rauskitzeln.

Dass das AES zum Flaschenhals wird glaube ich nicht, eher das Netzwerk, ist schließlich nur Gigabit.

[foobar]

Wenn Du ein Programm kennst mit dem das geht bin ich ganz Ohr.

Für Diagramme:
http://www.jave.de/
https://metacpan.org/pod/distributio.../App/Asciio.pm
https://metacpan.org/pod/release/TEL...bin/graph-easy

Onlinedienste:
https://textik.com/
http://asciiflow.com/

Mehr für ASCII-Art:
http://aewan.sourceforge.net/

[Uripura]

Für Diagramme:
http://www.jave.de/
https://metacpan.org/pod/distributio.../App/Asciio.pm
https://metacpan.org/pod/release/TEL...bin/graph-easy

Onlinedienste:
https://textik.com/
http://asciiflow.com/

Mehr für ASCII-Art:
http://aewan.sourceforge.net/

Danke, das muss ich beim nächsten mal dann probieren.

Ich habe allerdings das nächste Problem:

Ich möchte das RAID5 anlegen mit einer Partition auf der SSD als journaling-device.
Aber ich bekomme beim erstellen nur eine kryptische Fehlermeldung.

root@nas ~# blkid
/dev/sda1: UUID="3218-D009" TYPE="vfat" PARTUUID="6c4db833-e002-9b4a-8597-db5934455f3f"
/dev/sda2: UUID="7aefe7e5-935e-4c77-8a29-c89f52abbf2b" TYPE="crypto_LUKS" PARTUUID="c2fdab8e-996b-4a47-991b-303b96c2a151"
/dev/sda3: UUID="170e617b-57fd-451a-81f3-1af277acc9cc" TYPE="swap" PARTUUID="6c8868fd-2398-f84d-8479-027654f9fc89"
/dev/mapper/root: UUID="c4ef1966-b62c-43a8-b39c-23a955d621ae" TYPE="ext4"
/dev/sda4: PARTUUID="ed52d7f2-9937-b640-b6c2-a0b4d20c6c73"
/dev/sdb1: PARTUUID="ce856575-bbce-fd46-aca7-0b8b5a1e1462"
/dev/sdc1: PARTUUID="e5bb847d-362b-d140-9b1f-2858c7cd78c4"
/dev/sdd1: PARTUUID="db235b4c-8cb0-ff43-9800-d2f3ddbd519c"

root@nas ~# mdadm --create --verbose --level=5 --name=data-raid --metadata=1.2 --chunk=256 --raid-devices=3 /dev/md/data-raid /dev/sdb1 /dev/sdc1 /dev/sdd1 --write-journal=/dev/sda4
mdadm: layout defaults to left-symmetric
mdadm: size set to 3906837504K
mdadm: automatically enabling write-intent bitmap on large array
mdadm: RUN_ARRAY failed: Invalid argument

Wenn ich die Journaling OPtion weglasse wird das RAID ganz normal gebaut.
Ich habe schon die Mangṕage rauf und runter gelesen und im Internet finde ich auch nichts hilfreiches dazu. Kennt sich von euch vielleicht jemand damit aus?

[Petrus]

Ich kenne mich _nicht_ damit aus.

Aber vielleicht hilft das trotzdem?

If you receive an error, such as:

"mdadm: RUN_ARRAY failed: Invalid argument"
make sure your kernel supports (either via a module or by being directly compiled > in) the raid mode you are trying to utilize.

If I check /proc/config.gz, it contains this line:
CONFIG_MD_RAID0=m

(in deinem Fall hier evtl.: CONFIG_MD_RAID5=m).

CONFIG_MD_RAID0=m means your raid0 support is built as a module (m for module), and md: personality for level 0 is not loaded! says the module isn't loaded. To load it:

modprobe raid0

Then you should be able to create the array. Remember that you'll need to load the module every boot before assembling the array (you can and should have your boot scripts do this).

Linkage: https://unix.stackexchange.com/quest...creating-raid0

[Uripura]

Das hilft leider nicht, es kommt die gleiche Fehlermeldung.

Ich möchte eigentlich auch kein RAID0 haben, aber das Modul für RAID5 habe ich natürlich geladen.

[Lookbehind]

Mal doof gefragt: Was versprichst du dir von dem Journaling-Device?

[Uripura]

Mal doof gefragt: Was versprichst du dir von dem Journaling-Device?

Bei einem Stromausfall möchte ich nicht, dass Daten verloren gehen oder das ganze Array stundenlang gechecked wird.

Die Doku erklärt das ganz gut:

mdadm (supported since
3.4) has a new option '--write-journal' to create array with cache. Please
refer to mdadm manual for details. By default (RAID array starts), the cache is
in write-through mode.

[...]

write-through mode:

This mode mainly fixes the 'write hole' issue. For RAID 4/5/6 array, an unclean
shutdown can cause data in some stripes to not be in consistent state, eg, data
and parity don't match. The reason is that a stripe write involves several RAID
disks and it's possible the writes don't hit all RAID disks yet before the
unclean shutdown. We call an array degraded if it has inconsistent data. MD
tries to resync the array to bring it back to normal state. But before the
resync completes, any system crash will expose the chance of real data
corruption in the RAID array. This problem is called 'write hole'.

Ich habe aber schon die Lösung gefunden:

Anscheinen braucht es das Flag "--bitmap=none" damit es geht.
Ich bin drauf gekommen als ich in dmesg den Eintrag "[ 3806.067068] md/raid:md127: array cannot have both journal and bitmap" gesehen habe.
Zwar hatte ich in Erinnerung, dass die Flags implizit durch das "--write-journal" gesetzt werden sollten, aber ich habe es trotzdem probiert.

Und siehe da alles geht.

[Petrus]

Nach dem Linux in Bayern Ende 2017 und nach 12 Jahren in Niedersachsen Mitte 2018 rausgeworfen wurde, aber Schleswig-Holstein zumindest eine Absichtserklärung in Richtung Open Source zustandegebracht hat, gibt sich nun Südkorea die Ehre. Wie schaffen es diese verklärten Revoluzzer denn überhaupt gegen das massive Lobbying von Microsoft solche Anliegen durchzubringen?

[foobar]

Jetzt kippt der Süden auch zum Kommunismus um! Wird Zeit, dass die USA mal wieder etwas Freiheit dort vorbei bringen.

[Lookbehind]

Ich hab dann auch noch mal n Problem. Oder besser, ich hab was vor, und grübel darüber, wie ich es anstellen soll.

Ich habe ein Programm das öfter mal ein paar Fehlermeldungen raus haut. Manchmal dauerts über 2 Wochen für eine Fehlermeldung, manchmal kommen gefühlt 20 pro Minute. Vermeiden lässt sich das nicht. Dafür müsste ich zu viele User die sich für die Technik dahinter nicht interessieren erziehen. Aber zu viele könnten auf weitere Probleme hindeuten. Um das aber beurteilen zu können, brauch ich erst mal eine einigermaßen verlässliche Übersicht darüber wie oft denn da wirklich Fehler fliegen. ... You can't manage, what you can't measure. ... Der Inhalt der Fehlermeldung ist übrigens nicht so relevant. Ist immer die selbe.

Tja, wofür hab ich da n Munin laufen? Der könnte mir doch schön nen Graph darüber zeichnen und ne Auflösung von 5 Minuten wäre auch erst mal locker ausreichend.

Ich habe also eine Anwendung, die Fehler nach STDERR schiebt und einen Cron-Job der alle 5 Minuten die Anzahl der Fehler erfassen soll. Aber wie bekomme ich die beiden zusammen?

Was ich nicht möchte ist einfach ein stumpfes Logfile, in welches ich die Meldungen rein schreibe. Zum einen, weil ich mir dann merken muss, wo ich mit lesen aufgehört habe, ich will ja die Anzahl der Fehler pro Zeiteinheit haben, nicht die Gesamtzahl. Zum zweiten würde ich eine Menge redundante Informationen speichern. Wie gesagt, es ist immer die selbe Meldung. Und außerdem belegt mir das meinen Plattenspeicher. Logrotate und solche Späße machen aber das Erfassen der Anzahl wieder kaputt.

Ideen, die ich bisher hatte:
1. Irgendeine "Spezialdatei", die bei einem touch oder einem ähnlichen Event, einen Wert hoch zählt und diesen auslesen kann. Bis mir in den Sinn kam, dass das eigentlich schon zu viel Logik für eine "Datei" ist. Wirds vermutlich nicht geben.
2. Ein FiFo in welchen ich die Fehlermeldungen rein schreibe. Dann könnte ich die von dem Cron-Job auslesen lassen, der könnte die Meldungen zählen und da es ein FiFo ist, wären die Meldungen anschließend auch wieder raus. Nachteil: Beim schreiben in den FiFo kommt der Prozess erst zurück, wenn der entsprechende Eintrag aus dem FiFo gelesen wurde. Inakzeptabel!
3. Ein "Datei-Wechsel" System. Eine "current" Datei, in welche die Fehlermeldungen geschrieben werden. Der Cron-Job verschiebt die "current" Datei nach "last" und legt eine neue "current" Datei an. Anschließend zählt er die Fehlermeldungen in "last" und löscht die "last" Datei anschließend wieder. Problem: Das verschieben und neu anlegen der Datei ist nicht atomar. Und das für quasi parallele Prozesse ... was soll schon schief gehen?

Muss ich mir echt n Daemon schreiben, nur um Fehlermeldungen zu zählen?

Irgendwie hab ich das Gefühl, dass das doch irgendwie einfacher gehen müsste. Oder ist das doch so ein exotischer Anwendungsbereich? Gibts da nix von Ratiopharm?

[foobar]

Bin kein Experte, was Munin betrifft. Also eher so allgemein und natürlich wie immer bei mir aus der Hüfte geschossen:

3. Ein "Datei-Wechsel" System. Eine "current" Datei, in welche die Fehlermeldungen geschrieben werden. Der Cron-Job verschiebt die "current" Datei nach "last" und legt eine neue "current" Datei an. Anschließend zählt er die Fehlermeldungen in "last" und löscht die "last" Datei anschließend wieder. Problem: Das verschieben und neu anlegen der Datei ist nicht atomar. Und das für quasi parallele Prozesse ... was soll schon schief gehen?

Der Wechsel an sich sollte kein Problem sein, weil das VFS von Linux das abfängt. Das Problem ist eher, dass du für den Wechsel der Datei den schreibenden Prozess wissen lassen musst, dass er sie neu öffnen soll. Ansonsten behält der nämlich den Inode der ursprünglichen Datei geöffnet und schreibt weiter fröhlich da rein. Dass die inzwischen anders heißt, kümmert ihn nicht weiter (deshalb gibt es da auch keinen Konflikt).

Wenn man den Prozess auf irgendeine Weise (z.B. mit einem SIGHUP oder einem nicht störenden Respawn) dazu kriegen kann, die Datei neu zu öffnen oder er sowieso immer wieder neu gespawnt wird und nicht durchläuft, dann müsste das eigentlich funktionieren. Entweder die "current" ist noch da, dann geht's da rein. Oder sie ist schon weg, dann wird der erste Schreiber sie neu erstellen (auch wenn man den "Anhängen-Operator" '>>' benutzt) und der nächste hat sie dann. Wenn sie zufällig gerade umbenannt wird, während ein Prozess rein schreibt, sollte nix Schlimmes passieren. Der Eintrag landet halt noch in der selben, nun "last" heißenden Datei.

Eine Alternative wäre, ein ganzes Verzeichnis dafür zu nehmen. Jedes Mal, wenn's kracht, legt man eine Datei mit eindeutigem Namen an (z.B. nach dem Schema YYYY-MM-DD-HH-MM-SS-PID). Zur Auswertung zählt man die Dateien und löscht dann alle, die älter als die jüngste zuletzt gezählte Datei sind.

Vielleicht hilft dir auch einfach ein Shellskript, das bei jedem Fehler aufgerufen wird und den Zähler erhöht oder was auch immer. In das Skript baust du dann einen Locking-Mechanismus ein, damit es nur einmal Laufen kann. Alle anderen müssen warten, bis der erste fertig ist. In etwa so (ungetestete Skizze):

LOCKDIR=/tmp/errorcounter.lock
MAXTRIES=100

while true; do
  if mkdir "$LOCKDIR"; then
    # Das Erzeugen hat geklappt, wir sind also der erste
    # Erhöhe Zähler oder was auch immer
    # ...
    rmdir "$LOCKDIR" # Lock wieder freigeben
  else
    sleep 1 # kurz warten, dann nochmal probieren
    count=$(($count+1))
    if [ $count -gt $MAXTRIES ]
      # Timeout beim Warten, abbrechen
      exit 1
    fi
  fi
done

Da 'mkdir' tatsächlich atomar ist beim Prüfen und Erzeugen von Verzeichnissen, kann man es als "Mutex für Arme" benutzen.

[Lookbehind]

Ha! Da hatte ich doch glatt einen Denkfehler!
Ja, der Prozess stirbt regelmäßig und wird neu gespawnt. Was aber auch ok ist, weil er nur on demand gestartet wird. Mein Denkfehler war, dass ich daran dachte, dass eine Datei verschieben und eine neue "curent" erstellen ja eben 2 Operationen sind, die auch das VFS nicht atomisieren kann. Woran ich nicht gedacht habe ist, dass die neue "current" ja noch gar nicht da liegen muss, und ich die ja mit dem ersten schreiben einfach anlegen kann. ... war wieder viel zu einfach.

Danke für den Hint!

Ach ja, die Munin-Seite des ganzen ist ein beliebiges Shell-Script oder jede weitere beliebige Binary oder Script-Datei, welche alle 5 Minuten per Cron aufgerufen wird, die Werte nach der darin hinterlegten Logik bestimmt und in einem vorgegebenen Format ausspuckt. Simple as can be.

[foobar]

Ich habe mal einen neuen Thread eröffnet, damit das Forum nicht explodiert, weil wir die 400er-Marke überschritten haben.