Auch wieder wahr. Und nur nicht Folgen zum Löschen geht logischerweise nicht.
Löschen von Aufnahmen und symlinks
-
Zum testen mal "cp --reflink=always originaldatei kopie" eingeben
Sehr gut
- das scheint besser als der Symlink zu sein, denn der VDR löscht damit quasi nur die "verlinkte" Datei, nicht das Original, wenn der Pfad eben zur reflink-Kopie geht. Sogar, wenn versehentlich das Original gelöscht wird, ist es immer noch da - erreichbar unter dem alternativen Pfad.Reflinks verwende ich auch schon unter xfs (und btrfs ohnehin).
Und: ein reflink ist dasselbe wie ein Hardlink, d.h. er braucht keinen zusätzlichen Platz, solang an keiner der beiden Dateien was verändert wird.
Und, der wichtigste Vorteil: reflink funktioniert auch für Verzeichnisse!
-
Ja, aber das empfohlene Format für die Video-Platte ist ohnehin "traditionell" xfs.
-
Kann ext4 leider nicht:
Stimmt, dann kanst Du aber hardlink nehmen, was quasie das gleiche ist, und das geht auch mit ext4.
Man kann dann auch "cp --link quelle ziel" machen, dann wird das auch zum hardlink. Das geht aber leider nur mit Dateien.
Grüße
kamel5
-
Ja, aber das empfohlene Format für die Video-Platte ist ohnehin "traditionell" xfs.
Tja, hatte ich auch. Allerdings hat das damals nur Probleme gemacht. Seit ich wieder auf ext4 zurück bin, hatte ich kein einziges Problem mehr.
Das Teil ist halt auch riesig - 72 TB RAID5.
-
Stimmt, dann kanst Du aber hardlink nehmen, was quasie das gleiche ist, und das geht auch mit ext4.
Man kann dann auch "cp --link quelle ziel" machen, dann wird das auch zum hardlink. Das geht aber leider nur mit Dateien.
Grüße
kamel5
D.h. ich muss mein Hauptverzeichnis sowie das .rec Verzeichnis im Script selber anlegen und dann die Dateien rüber linken.
Das würde den Fall abdecken, dass etwas aus "neue Aufnahmen" entfernt werden, aber im eigentlichen Aufnahmeverzeichnis stehen bleiben soll.
Was ich leider bisher vergessen habe: Wenn aus dem eigentlichen Aufnahmeverzeichnis etwas entfernt wird, wird momentan vom Script auch der Rest im "neue Aufnahmen" Verzeichnis weg geputzt. Erkannt wird das über den dann toten .del-Link.
Sieht jetzt aus wie folgt. Die Loops sind nur deswegen drin, weil ich die Meldungen für jede einzelne Datei möchte. Sonst könnte man den finds auch jeweils ein "-delete" mitgeben.
Code
Alles anzeigenif [ -n "$VDR_NEWREC" -a -d "$VDR_NEWREC" ] then LINKDIR=$( dirname "$RECORDING" ) LINKDIRD=$( dirname "$LINKDIR" ) if [ -n "$LINKDIRD" -a "$LINKDIRD" = "$VDR_NEWREC" ] then # Link auf Aufnahmeverzeichnis löschen while read l do $REPORT "deleting link ${l}" rm "$l" ret_val=$? case "$ret_val" in 0) $REPORT "OK." ;; *) $REPORT "Error ${ret_val}!" ;; esac done <<< $( find "$LINKDIR" -type l ) # kaputte Links loeschen # z.B. wenn das Originalaufnahmeverzeichnis vorher geloescht wurde while read l do $REPORT "deleting dangling link ${l}" rm "$l" ret_val=$? case "$ret_val" in 0) $REPORT "OK." ;; *) $REPORT "Error ${ret_val}!" ;; esac done <<< $( find "$VDR_NEWREC" -xtype l ) # leere Verzeichnisse loeschen while read l do $REPORT "deleting empty directory ${l}" rmdir "$l" ret_val=$? case "$ret_val" in 0) $REPORT "OK." ;; *) $REPORT "Error ${ret_val}!" ;; esac done <<< $( find "$VDR_NEWREC" -empty -type d ) fi fi -
Bei Hard- oder reflinks gibt es aber keine "toten Link"-Einträge - da muß am Script ohnehin was geändert werden.
Was mich wundert: xfs ist gerade für große Dateien und Dateisysteme gut gerüstet und hat bei mir so überhaupt keine Probleme bereitet.
Auch btrfs wird immer besser und stabiler, und so ich weiß, aber schon lange nicht mehr getestet habe, läßt sich ext4 auch in btrfs konvertieren, sofern noch genügend Platz auf der Partition ist. Es gibt auch sogar unter ubuntu/debian das "fstransform"-Tool, das sollte ext4 in xfs konvertieren können. Bei neueren Kernels ist der reflink-Support schon standardmäßig aktiv, so ich weiß.
-
D.h. ich muss mein Hauptverzeichnis sowie das .rec Verzeichnis im Script selber anlegen und dann die Dateien rüber linken.
Das würde den Fall abdecken, dass etwas aus "neue Aufnahmen" entfernt werden, aber im eigentlichen Aufnahmeverzeichnis stehen bleiben soll.
Genau.
Was ich leider bisher vergessen habe: Wenn aus dem eigentlichen Aufnahmeverzeichnis etwas entfernt wird, wird momentan vom Script auch der Rest im "neue Aufnahmen" Verzeichnis weg geputzt. Erkannt wird das über den dann toten .del-Link.
Sieht jetzt aus wie folgt. Die Loops sind nur deswegen drin, weil ich die Meldungen für jede einzelne Datei möchte. Sonst könnte man den finds auch jeweils ein "-delete" mitgeben.
Das funktioniert dann nicht mehr so einfach. Für das System sind das dann 2 halb verschiedene Verzeichnisse, obwohl nur einmal Platz gebraucht wird.
Veränderungen im Originalverzeichnis wirken sich dadurch bei ext4 auf untersciedliche Art im kopierten Verzeichnis aus:
Löschungen im Originalverzeichnis wirken sich nicht aus.
Veränderungen an Dateien im Originalverzeichnis wirken sich aus.
Neue Dateien im Originalverzdichnis werden nicht autom. übernommen.
Grüße
kamel5
-
Bei Hard- oder reflinks gibt es aber keine "toten Link"-Einträge - da muß am Script ohnehin was geändert werden.
Was mich wundert: xfs ist gerade für große Dateien und Dateisysteme gut gerüstet und hat bei mir so überhaupt keine Probleme bereitet.
Auch btrfs wird immer besser und stabiler, und so ich weiß, aber schon lange nicht mehr getestet habe, läßt sich ext4 auch in btrfs konvertieren, sofern noch genügend Platz auf der Partition ist. Es gibt auch sogar unter ubuntu/debian das "fstransform"-Tool, das sollte ext4 in xfs konvertieren können. Bei neueren Kernels ist der reflink-Support schon standardmäßig aktiv, so ich weiß.
Bei so einem großen Dateisystem würde ich solche Experimente ohne Backup aber nicht machen.
Ich habe auch schon mal ext4 in btrfs transformiert und hatte hinterher immer wieder Probleme.
Grüße
kamel5
-
Das stimmt natürlich, Backup rulez, braucht aber Platz - vermutlich eine 2. (neue, ggf. externe) Platte. Für die Video-Platte mal einfach ein leeres xfs erzeugen auf der neuen Platte, die Daten rüberkopieren, und dann die alte ext4-Platte als Backupmedium weiterverwenden (ggf. ins externe Gehäuse, wo urprünglich die neue Platte drin war, einbauen).
-
Bei Hard- oder reflinks gibt es aber keine "toten Link"-Einträge - da muß am Script ohnehin was geändert werden.
Was mich wundert: xfs ist gerade für große Dateien und Dateisysteme gut gerüstet und hat bei mir so überhaupt keine Probleme bereitet.
Auch btrfs wird immer besser und stabiler, und so ich weiß, aber schon lange nicht mehr getestet habe, läßt sich ext4 auch in btrfs konvertieren, sofern noch genügend Platz auf der Partition ist. Es gibt auch sogar unter ubuntu/debian das "fstransform"-Tool, das sollte ext4 in xfs konvertieren können. Bei neueren Kernels ist der reflink-Support schon standardmäßig aktiv, so ich weiß.
Ja, trotzdem würde ich so ein Konvertieren nur machen, wenn ich vorher die Daten irgendwohin sichern könnte, was bei der aktuellen Größe momentan leider mangels entsprechender Backupkapaziät nicht geht.
wenn der nächste Sprung in der Kapazität ansteht, werde ich mir eh wieder alles von vorne ansehen und testen.
-
Das stimmt natürlich, Backup rulez, braucht aber Platz - vermutlich eine 2. (neue, ggf. externe) Platte. Für die Video-Platte mal einfach ein leeres xfs erzeugen auf der neuen Platte, die Daten rüberkopieren, und dann die alte ext4-Platte als Backupmedium weiterverwenden (ggf. ins externe Gehäuse, wo urprünglich die neue Platte drin war, einbauen).
Naja, für die Größe mal eben *eine* neue Platte` mit 72 TB?
-
D.h. ich brauche 4 x 22 TB für ein neues RAID5
Und was passiert, wenn dann eine Platte ausfällt ? Der Rebuild nach dem Tausch müsste dann 3 x 22 TB ohne einen Bitfehler lesen. Das wäre mit Consumer Platten eher unwahrscheinlich.
-
Dasy video0 bis x zusammenlinken gibt es nicht mehr. Ggf. noch per distributedvideodir Plugin wieder herstellbar. Das ist mir aber nicht gelungen bisher.
Das Verteilen von neuen Aufnahmen auf mehrere Platten wird nicht mehr offiziell unterstützt.
Der Rest ist aber drin geblieben.
SurfaceCleanerZ :Ich habe inzwischen eine Idee, wie man für den User aufschlussreichere Logmeldungen raus bekommt, ohne den ganzen Syslog zu zu müllen. Bin aber leider noch nicht dazu gekommen, das umzusetzen.
define DELETEDLIFETIME 300 // seconds after which a deleted recording will be actually removed
Dass es eine extra DELETEDLIFETIME gibt, wusste ich noch nicht, wieder was gelernt.
Das erklärt auch, warum ich bislang immer Glück mit dem undelete-Plugin hatte
.So was in der Art kann man mit dem Plugin "recsearch" machen.
Danke für den Tipp!
-
Naja, für die Größe mal eben *eine* neue Platte` mit 72 TB?
Das ist schon eine große Sammlung
Ich hab nur eine 8TB-Platte mit einer 2. externen, die regelmäßig ge-rsynced wird, mit verzögertem Löschen.
Um mehr Platz zu kriegen, konvertiere ich alles nach der Aufnahme in hevc.
-
Und was passiert, wenn dann eine Platte ausfällt ? Der Rebuild nach dem Tausch müsste dann 3 x 22 TB ohne einen Bitfehler lesen. Das wäre mit Consumer Platten eher unwahrscheinlich.
Sind immerhin dedizierte Server-Platten. Aber ja, wenns kaputt ist, isses kaputt 8-<
Ich hatte das Jahrelang auf LTOs gesichert, aber dann ist das LTO-Laufwerk gefreckt und war eigentlich auch schon am Anschlag. Und ein neues war mir dann doch zu teuer - die LTO9 kosten ja 3 K aufwärts und können auch nur max. 50 TB.
-
Ich habe zwar nicht ganz so viel "Platte", aber auch schon knapp 50TB im Server, da wäre mir allerdings ext4 auch zu unsicher.
Ich habe vor Jahren mal mit btrfs experimentiert und konnte mich damit nie so richtig anfreunden, das Händling ist mir einfach zu unübersichtlich und dann fehlte mit damals die native raid5 Unterstützung.
Ich habe mich dann nach langen Überlegen für zfs als Dateisystem entschieden, und habe das bis heute nicht bereut.
Ein Backup (täglich) mache ich da nur für meine wichtigen persönlichen Daten, wie Fotos, Videos vom Handy, Dokumente etc. Sonstige Videos (Aufzeichnungen vom VDR und andere mkv's) lasse ich außen vor, das bekommt man im Fehlerfall meistens irgendwo wieder her.
Grüße
kamel5
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!