hawihoney

Server und WLAN widersprechen sich einfach. Hier die drei Einsatzszenarien von der Unraid Website. Da passt WLAN nun wirklich nicht: Network-Attached-Storage/Application Server/Virtualization Host Wenn ich in Deiner SItuation wäre, dann würde ich mir einen WLAN-Repeater mit LAN Buchse o.ä. kaufen.

Achtung: Löscht keine Verzeichnisse sondern nur Dateien. Musst noch einen find mit -type d -empty -delete anhängen. Im Grunde genommen läuft es auf etwas Ähnliches wie das hinaus: rsync -av --remove-source-files <source> <target> && find <source> -type d -empty -delete

Such mal in diesem Board nach dem Plugin "User Scripts". Mit dem Plugin kann jedes Skipt zeitgesteuert aktiviert werden. Fehlt nur noch der passende Befehl fürs Verschieben. Den trägst Du dann dort ein.

In meinem Fall ging es nicht um Python v2 vs. Python v3 sondern um Python v3 3.9 vs. Python v3 3.6. Da gab es Inkompatibilitäten in den Tools aus Nerd- bzw. Dev-Pack. Wenn Du nach v2 vs. v3 fragst, lass die Finger von v2. Ist 2020 ausgelaufen. Es gibt syntaktisch einige gravierende Änderungen wie schon simple Dinge wie "print 'x'" vs. "print('x')". Returntypen von Funktionen können unterschiedlich sein, etc. etc.

Hab gerade mal nachgeschaut. Bis auf zwei, sind alle Container von Linuxserver.IO (swag, mariadb, nextcloud, nzbget, plex). Die beiden anderen von jlesage. Wobei ich mich gerade frage, wieso makemkv und mkvtoolnix nicht von Linuxserver.IO zur Verfügung gestellt werden ...

ich will das jetzt nicht groß zum Thema machen, aber für mich ist das wirklich kein Argument. Wie man hier vielleicht mitbekommen hat, stamme ich aus einer ganz anderen Generation - bin schon lange Privatier. Ich musste noch kommerzielle Assembler Programme in 1 KB RAM unterbringen. Der verschwenderische Umgang mit Resourcen - nur weil man sie hat - lehne ich bei Programmen/Anwendungen kategorisch ab. Wie gesagt, das ist meiner EDV/IT Ausbildung geschuldet die in den 70ern des letzten Jahrhunderts startete. So manches Framework ist so groß, da passten meine dutzend letzten kommerziellen Anwendungen (C, Android/Java) aus Anfang 2000 locker zusammen rein - ohne zusätzliche Frameworks. Wenn es keinen gravierenden fachlichen oder sachlichen Unterschied zwischen zwei gleichartigen Anwendungen gibt, werde ich immer die kleinere nehmen.

Was ist eigentlich der Unterschied für mich als Benutzer zwischen den verschiedenen Containern? Ich las vor einiger Zeit das ich777 Container auf Apache basieren, andere auf Alpine. Was bedeutet das für mich? Sind die kleiner, größer, schneller, langsamer oder gibt es gar Unterschiede im Funktionsumfang bzw. dem Handling? Vielen Dank.

Nur noch mal als Warnung: Meine oben gezeigten rsync Parameter synchronisieren. Ein reines Kopieren ginge anders. Wie gesagt, man muss die Parameter - und die Nutzung des jeweils letzten '/' - vom genauen Einsatzzweck abhängig machen. Mein Skript oben synchronisiert zwei Verzeichnisse. Das kopiert: rsync -av /mnt/user/<Sharename1>/ /mnt/user/<Sharename2>/

Auf diese Weise landet alles, was im Container temporär nach /tmp geschrieben wird, im RAM. /bla ginge auch, aber was/wer schreibt schon in /bla? Ich hatte eine gewisse Zeit /tmp meiner Container überwacht und bei intensiver Nutzung für diese Container das Mapping geändert: Host: /tmp/<Containername> Container: /tmp

Schon klar, war eher eine Zwinkerfrage. Hatte mir die Einsatzgebiete, sowie Pros und Contras, zwischen /tmp, /var/tmp und dev/shm schon vorher durchgelesen. Ich bin mit /tmp bisher extrem gut gefahren. Noch nie ein Problem. Mit anderen Varianten hatte ich schon mal Probleme. Das /tmp/<containername> <--> /tmp Mapping hat den geschmeidigen Vorteil, dass auch andere temporäre Dateien der jeweiligen Container dort landen. Da bei mir jede Nacht alle Container per User Script gestoppt, gesichert und wieder gestartet werden, sehe ich da eher kein Problem. Allerdings überlege ich getrade, in dem zugehörigen User Script vorsichtshalber noch ein Löschen des jeweiligen /tmp Bereich des Containers einzubauen. So etwas wie: docker stop <containername> rsync <container> <container_backup> rm /tmp/<containername> docker start <containername>

/tmp unter Unraid ist dann eine 100% RAM Disk (minus den laufenden Kram), oder

Am 16.09.2021 starb Sir Clive Sinclair, der Entwickler diverser Kleincomputer wie Sinclair ZX80, ZX81, ZX Spectrum und QL - die ich in genau dieser Reihenfolge besaß - und für die ich meine ersten Programme entwickelte und verkaufte. Ohne Sinclair und seine Produkte wäre ich nie in die IT (FKA EDV) eingestiegen. Sinclair war ein Visionär. Manche Produkte waren genial, manche kolossale Flops. Eine BBC Doku mit dem Titel "Micro Men (2009)" u.a. mit Martin Freeman dreht sich um Sinclair und u.a. seinen Geschäftspartner Chris Curry. Programmiert wurden die Geräte zunächst in Zilog Z80 Assembler, spätere seiner Produkte in Motorola 68008 Assembler. Der ZX80 zum Beispiel besaß 4 KB ROM und 1 KB RAM. An den Rechner hing man dann einen TV (Koax) und einen Kassettenrekorder für die Programme. Programme wurden auf 15 min Kassetten (wie Musik Kassetten) geliefert. Der Zilog Assembler war z.B. auf der A-Seite der Kassette, der zugehörige Linker auf der B-Seite der Kassette. Zum Übersetzen eines Assembler Programmes lief zunächst der Compiler 15 Minuten lang, dann der Linker 15 min lang. Wenn man dann einen Fehler beim Linken feststellte, dann begann man wieder von vorne: Kassette mit Sourcecode laden, Sourcecode ändern, Sourcecode auf Kassette speichern. Compiler Kassette in das Kassettendeck einlegen usw usf. Später gab es eine externe 16 KB RAM Erweiterung, die ich eigens in England kaufte, sowie Microdrives, die die Kassetten teilweise ablösten. Später habe ich mit Kumpeln eine Adapterplatine gebaut und einen zugehörigen Treiber. Damit konnten wir eine 5 MB IBM Festplatte an den Sinclair QL anschliessen. Die Programmierung unter diesen Voraussetzungen hat mich nachhaltig beeinflusst. Hier einige Links: https://de.wikipedia.org/wiki/Clive_Sinclair https://de.wikipedia.org/wiki/Sinclair_ZX80 https://de.wikipedia.org/wiki/Sinclair_ZX81 https://de.wikipedia.org/wiki/Sinclair_ZX_Spectrum https://de.wikipedia.org/wiki/Sinclair_QL https://de.wikipedia.org/wiki/Microdrive_(Bandlaufwerk) Auf diese Anzeige hin habe ich in 1980 meinen ersten Sinclair ZX80 erworben:

Nein, es war aber auch noch nie ein Problem. 4x 4K Transcode hatte ich schon, 5x 4K Transcode noch nie. Der Plex Server ist in dieser Angelegenheit eigentlich ausgereift. Die GUI auf den diversen Klienten ist da schon eher das Problem.

Das User Scripts Plugin wäre eine Variante. Du legst dort ein neues Skript an, gibst diesem einen Namen (e.g. "Sync Share1 nach Share2") und in dem Script trägst Du etwas wie folgt ein: #!/bin/bash #arrayStarted=true #clearLog=true #noParity=true #Achtung: An der Quelle gelöschte Dateien werden am Ziel ebenfalls gelöscht (AKA Sync) rsync -avPX --delete-during /mnt/user/<Sharename1>/ /mnt/user/<Sharename2>/ Das "Schedule" für dieses Skript setzt Du auf "Custom" o.ä. und in das dann erscheinende Eingabefeld dahinter trägst Du "0 * * * *" ein (natürlich alles ohne die Anführungszeichen). Nach dem Bestätigen mit "Apply" o.ä. wird Dein Skript zu jeder vollen Stunde zur Minute 0 ausgeführt. Je nachdem was Du erreichen willst, solltest Du die rsync Parameter checken.

Je nach verfügbaren RAM kannst Du das Plex Transcoding auf das RAM umbiegen. Das haben viele hier entsprechend konfiguriert. Es gibt hierzu zwei Techniken. Ich nutze einfach einen Ordner unterhalb von /tmp (/tmp/plex) auf dem Host und reiche diesen im Container Mapping an den Container (/tmp). Der /tmp/plex Ordner auf dem Host muss natürlich für den Container beschreibar sein. So läuft das bei mir seit Jahren. Hab allerdings auch 128 GB verbaut. Je nach verwendetem Plex Container gibt es bereits vorkonfigurierte Mappings für Transcode - die muss man dann nur entsprechend mit einem Ordner auf dem Host füllen. Das neue und aufwändige Sonic Music Matching von Plex mit seinen Temp Dateien läuft übrigens bei mir auf diese Weise ebenfalls im RAM. Dadurch klappt das erheblich schneller. Ich hatte kurzfristig mal auf eine andere RAM Variante umgestellt, die hatte aber nach ein paar Runden meinen Rechner bis zum Stillstand gehimmelt. Das werde ich nicht mehr nutzen.

Temporäre Plex Transcoder Dateien auf ein verschlüsseltes Drive zu legen halte ich persönlich für überflüssig. Unabhängig davon kann ich mir sehr gut vorstellen, dass ein zusätzlicher Layer für die Verschlüsselung Performance frist. Ich habe von 25-50% je nach Quelle im Web gelesen - abhängig natürlich von genutzter Prozessor-Power und Software- vs. Hardware-Verschlüsselung. Ich persönlich arbeite nicht mit Verschlüsselung. Z.B. NVMe und LUKS: https://unix.stackexchange.com/questions/615159/nvme-performance-hit-when-using-luks-encryption

Dein transcode Mapping zeigt auf /mnt/user/PlexTemp. Was verbirgt sich dahinter? Ist das das Array (Disk7) oder ein Cache/Pool (cache_sata)? Ich hoffe letzteres und unverschlüsselt. Laut Deiner Diagnostics scheinen die Pools verschlüsselt zu sein. Das hätte IMHO drastische Auswirkungen auf den Plex Transcoder. Das Array wäre als Transcoder Temp auch sehr schlecht. Wie ist das genau konfiguriert?

Das ist so richtig. Nach der Installation mittels Docker erfolgt die weitere Administration immer über die installierten Anwendungen oder entsprechende Hilfswerkzeuge - hier über mySQL CLI bzw. phpMyAdmin GUI.

Vorab eine Frage: Müssen diese Backup Platten für Dich lesbar sein (auf einem Windows Rechner z.B.)? Zwischen Deinen Zeilen entnehme ich das. Oder wird das ein reiner Backup, der mit Backup/Restore Werkzeugen zurückgespielt werden kann - ohne das Du individuelle Dateien auf dem Dateisystem der Backupplatten einsehen kannst. Die Entscheidung darüber beeinflusst mögliche Lösungen.

Weil der Mover für andere Zwecke designed ist. Der Cache (bzw. einer der Pools) soll die langsameren Schreibzugriffe auf das zentrale Array abfedern. Die langsameren Schreibzugriffe auf das zentrale Array resultieren aus der on-the-fly Aktualisierung der Parity Platte(n). Der Mover soll dann zu ruhigeren Zeiten (Nachts?) die neuen Daten auf das Array übertragen. Das ist sein Einsatzzweck. Also: Array <--> Cache/Pool und nicht Cache/Pool <--> Cache/Pool https://wiki.unraid.net/Manual/Overview#Cache

Was meinst Du damit? Stehen diese Passwörter in /etc/passwd ? Wieso Ordner msql? Meintest Du mysql?

Now on 6.9.2 and new, more powerful hardware this is still happening. The switching clocksource was the reason for the new hardware. Can't believe this is still a problem: root@TowerVM02:~# grep -i clockso /var/log/syslog Aug 25 09:47:29 TowerVM02 kernel: clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns Aug 25 09:47:29 TowerVM02 kernel: clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6a8bec17f92, max_idle_ns: 881590537929 ns Aug 25 09:47:29 TowerVM02 kernel: clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns Aug 25 09:47:29 TowerVM02 kernel: clocksource: Switched to clocksource tsc-early Aug 25 09:47:29 TowerVM02 kernel: clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns Aug 25 09:47:29 TowerVM02 kernel: tsc: Refined TSC clocksource calibration: 3696.019 MHz Aug 25 09:47:29 TowerVM02 kernel: clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6a8d4c18613, max_idle_ns: 881590899667 ns Aug 25 09:47:29 TowerVM02 kernel: clocksource: Switched to clocksource tsc Sep 1 11:43:10 TowerVM02 kernel: clocksource: timekeeping watchdog on CPU12: Marking clocksource 'tsc' as unstable because the skew is too large: Sep 1 11:43:10 TowerVM02 kernel: clocksource: 'acpi_pm' wd_now: 7b3afe wd_last: 5c3c9a mask: ffffff Sep 1 11:43:10 TowerVM02 kernel: clocksource: 'tsc' cs_now: 808c642ec585e cs_last: 808c5d4de753e mask: ffffffffffffffff Sep 1 11:43:10 TowerVM02 kernel: tsc: Marking TSC unstable due to clocksource watchdog Sep 1 11:43:10 TowerVM02 kernel: clocksource: Switched to clocksource acpi_pm

Ja, darauf warte ich auch schon etwas länger.

Es hält Dich aber niemand davon ab, beides parallel zu benutzen: So hast Du beide Optionen offen. Und ja, man müsste die Shares manuell anlegen. Aber in Zeiten von Skripten oder mächtigen Shell Befehlen ist das alles m.M.n. PillePalle.

Hab den Witz echt nicht verstanden. Man kann doch auch bei zwei Platten mit Disk Shares arbeiten <kratzend am Kopf, rätselnd>.