Ford Prefect

Dann ist es vielleicht doch gar kein 1GBit NIC in dem alten PC?
Kannst Du auf dem PC ml eine Linux-Live ISO booten, zB Fedora oder Ubuntu?...gibt es dann eine 1G Verbindung?
Zeig doch mal die Diagnostics des guten Stücks.

...den Entwickler fragen, ob das im Plugin vorgesehen ist...dann gibt es evtl. ne Art Tabelle im Quellcode, die man dann dafür nutzen kann.
Wenn der Quellcode zB auf github gehostet ist, dann könnte man einen Pull-Request mit den notwendigen Anpassungen generieren.
 
BTW: ist denn die Tasmota Dose selbst auf DE oder EN Version?

Die Links Deiner Bilder funktionieren nicht.
 
Ich nehme an, das ist eben das Basis-System des Igel, wenn er nicht direkt ein System über PXE findet.
 
Edit: ...und den unraid Stick selbst hast Du auch auf EFI-Boot "gestellt" (ein Verzeichnis "EFI" muss da sein, kein "-EFI" oder "_EFI"..im Zweifel das Verzeichnis umbenennen. 

Unraid läuft im RAM ... das System ist etwas anders aufgebaut, da sonst nach einem reboot alles weg wäre, was Du im Dateisystem live änderst.
probiere das S3-Plugin ... Du könntest auch versuchen den ethtool Befehl im GO (/boot/config/GO) File einzubauen und so nach dem Boot abzusetzen

...hast Du mal iperf3 im Terminal eingegeben?

Die Parity ist die einzige Disk, die nicht formatiert ist.
Packe alle anderen ex-Array Disks wieder in das Array.  Reihenfolge ist ohne Parity egal. Dann das Array starten,  dann stop und Parity wieder einbauen und als solche konfigurieren. Nach dem Start wird Parity neu gebaut/befüllt.

@eFrame OK, ich glaube ich hab da gestern mein Gehirn in nem anderen Modus gehabt.
Das stimmt natürlich nicht. Dem Switch ist es egal, managed oder unmanaged, wir gross die L2MTU ist, solange er hardwareseitig die Frame-Grösse unterstützt (max L2 MTU).
Die sollte eigentlich bei einem Switch, der Jumbo-Frames können soll gross genug sein, kann aber je nach Modell/Switch Chip unterschiedlich sein.
 
Die MTU, welche Du einstellst ist übrigens die L3-MTU, also IP-Layer...L2 Frames kommen dann noch dazu.
Daher auch Unterschiede im Support bei den Switch Chips (kaskadierende VLANs u.ä. erhöhen die Frame-Länge auf L2-level).
-> https://help.mikrotik.com/docs/display/ROS/MTU+in+RouterOS?preview=/21725296/135856347/MTU_general_explanation.jpg
Hier mal zwei Beispiele aus unterschiedlichen Geräten: 
 
 
Also 1500 ist Standard und sollte Dir die 10G Performance bringen.
Ob Dir 9000 was bringt kannst Du ja versuchen...nötig ist es nicht...das war der Hit bei TokenRing und 100M-Ethernet Verbindungen und bleibt halt in den Köpfen drin
 
Das wichige ist, dass Geräte es unterstützen müssen und das auch alle Endpunkte, die Pakete generieren oder empfangen sollen, gleich eingestellt sind.
Gibt hier auch Beispiele, MTU hin oder her, wo User überhaupt nicht in die Gegend von 10G Performance kommen....Es ist nicht das Heilmittel, wenn man nur 6G schafft...eher ob man 9.6Gbps oder 9.7Gbps schafft.

Nimm die zweite 8TB als unassigend device und kopiere die Daten der defekten DIsk da drauf (wird ja noch über Parity emuliert).
Damit hast Du ein Backup und kannst das Array umbauen (defekte Datendisk raus, 4TB Parity raus, ...)

Das kannst Du natürlich so machen, aber bedenke, dass dies einzekne NICs sind, ohne Switch-Chip und Hardware-Beschleunigung. Das muss also die CPU alles alleine schaffen.
Was ist das denn für ein MB und CPU?
Edit: achso, steht ja da oben  ... ja, das sollte schon gehen...ob es für alle 4x2.5G simultan full-duplex recht, weiss ich allerdings nicht.
 
Wenn alle Clients in einem Netz sind, braucht man sowas nicht.
 
Was heisst denn Speedtest?
Was genau hast Du denn da benutzt?
Verwende iperf ... auch ein interner Speedtest, zb OpenSpeedtest im Docker kommt nicht weit...der Browser begrenzt die Performance.
 
Wenn alle im gleichen IP-Segment sind ist der Router aussen vor.
 
Wahrscheinlich beides...die Sense kostet Dich nochmal extra Performance.
Mach in unraid einfach alle Netzwerk-Karten/Ports in eine Bridge...die funktioniert wie ein Switch, allerdings muss eben die CPU die Arbeit machen.
 
Ohne jetzt zu wissen, wie die Performance mit iperf ist, könnte ja Dein Board/die CPU schon überlastet sein...
In dem Fall bleibt nur der Switch....was auf Dauer wahrscheinlich die energetisch günstigste Lösung ist....wobei eben ein 2.5G Switch schon auch 1-2 x 10G Trunk/Uplinks haben sollte um zukunftssicher zu sein.
 
Nicht nötig, wenn alle Clients im gleichen IP-Netzsegment sind.
 
...mach mal die Tests mit iperf und alle NICs in der gleichen Bridge.

Welche Fehler sind das genau? Sieht man was in den Logs?
Wie alt waren die betroffenen Disks?..und die auf welche die Wiederherstellung lief?
Wie waren die Temperaturen der HDDs?
Ein LSI 2008er Controller ist älter als 5 Jahre (ich habe welche, die sind 12 Jahre im Einsatz) oder ein China Fake....woher war der, neu oder refurbished aus einem echten Server, von einem guten Verwerter/renommierten Verkäufer?
Was für Kabel sind da am Start?
 
Du kannst die unassigned Devices Plugins installieren. Da ist dann auch das preclear dabei...
Ich mache bei jeder neuen HDD ein preclear (1x Durchlauf, write/verify)...bei einer gebrauchten mache ich Minimum 2x ... es kommt durchaus vor, das neue Disks schnell kaputt gehen. Daher eben preclear. Wenn sie das überleben ist die Chance gut.
 
Das ist kein unraid Problem....das Upgrade zur selben Zeit hat nix zu bedeuten/ist höchstens schlechtes Karma....Ursache ist wahrscheinlich die hohe Last durch die Transfers. Eine oder mehrere Komponenten haben halt aufgegeben. HDDs und oder Controller, oder auch das NT bzw Stromversorgung/Adapter zur Backplane.
Ursachen können sein, zu hohe Temperaturen z.B. auch durch Lüfterausfall und es meldet sich ne kalte Lötstelle/eine schlechte Verbindung...Pech mit der Hardware, kommt uch bei Markenware vor oder China Fakes...die geben meist nach 1 Jahr Einsatz auf.
Ich habe unraid Server mit jahrelanger Uptime...
Du hat einfach Pech gehabt.

Das hat nix mit der Auslastung des ZFS Pools zu tun. ZFS hat standardmässig einen Lese-Cache (ARC) im RAM. Unraid reserviert einen Anteil des RAM vom unraid Host dafür.
Die Anzeige sagt, das dieser cache zu x% gefüllt/benutzt ist.....reine Information, nix kritisches, egal wie gross oder klein dieser %-Wert ist.

Ich weiss tatsächlich nicht, was ich Dir darauf antworten soll/kann.
 
Du scheinst gedanklich in einer Zwickmühle zu stecken.
Die Frage in erster Linie wäre, was Du wirklich erreichen willst (brauchst Du bestimmte Features von unraid, die es nur im v612RC gibt?), in zweiter Linie, welche Risiken Du dabei eingehst, wenn Du einen RC einsetzt.
 
Hier mal meine subjektiven 2cent:
gibt es eine allgemeine Empfehlung für den Einsatz von BTRFS oder ZFS auf dem cache/Primary Storage?
-> Nein, weil es die ja für einen RC nicht geben *kann*.
Aktuell, wenn Du Redundanz für den Cache willst, ist die Empfehlung BTRFS weil nur das in v6.11 drin ist.
Ob es eine andere Empfehlung - zB für ZFS - geben wird, sobald v6.12 offiziell ist - weiss ich nicht. BTRFS und ZFS für sich betrachtet...ist ZFS neue Technologie/ist BTRFS bewährte Technologie
ZFS in unraid ist neu, aber genaugenommen ist ZFS von seiner Entstehungsgeschichte her viel älter und in viel mehr Installationen/grösseren Infrastrukturen im Einsatz als BTRFS . In Linux, vor BTRFS gab es ReiserFS (praktisch eine one-man-show), IBM hat (via Redhat) dann in BTRFS investiert und es in den Linux-Kernel eingebracht. ZFS kommt von SUN Solaris, was eine ganz andere Kernel-Architektur hat, als Linux...die erste, native Linux Implementierung ZoL (ZFS-on-Linux) ist/war daher nie ein direkter Ableger von ZFS von Solaris, sondern immer mit viel extra "Glue-Code" verbunden. Mit openZFS ist das aber praktisch Geschichte.  Was ist stabiler/verursacht weniger Probleme (allgemein/in unraid)?
Ich denke, das ist aktuell von der persönlichen Erfahrung und Vorlieben abhängig.
BTRFS hat in unraid eben die längere Historie...daher wird man auch viele User finden, die damit Probleme haben....vielleicht noch mehr, haben keine, aber die findet man dann nicht im Forum.
User, die schon auf anderen Plattformen mit ZFS (TrueNAS, Proxmox, Linux, Solaris) ihre Erfahrungen gemacht haben werden diese auf unraid "übertragen".
Wenn positiv -> nimm ZFS auf unraid, wenn negativ -> nimm kein ZFS
Genauso eben mit BTRFS...wenn keine Probleme, aber keine Erfahrung mit ZFS -> warum wechseln?
P.S.: ich gehöre zur Fraktion mit viel positiver ZFS Erfahrung und letztlich sehr negativer Erfahrung mit BTRFS...hätte es keine v6.12beta/RC gegeben, hätte ich meine unraid Server wieder beerdigt und wäre auf Proxmox o.ä gegangen. konkreter Einsatzzweck Cache/Primary Storage mit Redundanz
Redundanz heisst eben einen Raid-Level (für zwei Disks Raid1/Mirror) nutzen. Ob BTRFS oder ZFS ist unraid selbst egal.
Mit ZFS kommen weitere Features, die in v6.13 weiter integriert werden (zB in s UI, Plugins, statt CLI) - snaps und Replication, zum Beispiel).  Risiko, wenn man sich für "die falsche Fraktion" entscheidet
Die Prozedur, den Cache/Primary Storage auf einen anderes FS umzustellen bzw. analog die Disks zu tauschen/zu ergänzen ist hinlänglich bekannt.
Es kostet Zeit und Arbeit...da man das nicht täglich macht, gibt es das Risiko, dass man was falsch macht / nicht das gewünschte Ergebnis erzielt.
Wer Backups hat ist klar entspannter...ansonsten gibt es kein wesentliches Risiko.

Jein, wenn der Server unerreichbar ist und Du nicht im lokalen GUI Modus mit Monitor und Tastatur agieren kannst, bleibt Dir nur der Hard-Reset.
je nachdem, was Du bis zum Crash aktiv hattest, was Daten aufs Array schreibt/verändern könnte, können diese Daten ein Problem haben: https://docs.unraid.net/unraid-os/manual/troubleshooting#unclean-shutdowns
 
Wichtg wäre also, rauszufinden, was das Problem verursacht haben könnte.
Evtl. im GUI Mode mit Monitor und Tastatur starten, dann inn den Settings die Speicherung des Syslog auf den Stick aktivieren.
Wenn das Problem danach wieder auftritt, die Diagnostics erzeugen und hier posten
...evtl ist ein ein Hardware Problem .. auch ein defekter Stick kann Probleme machen.

Ja, mit zwei kleinen Einschänkungen:
unraid Host muss natürlich laufen und das Array gestartet sein (Klugscheisser Mode, ich weiss ) die Dateien dürfen nicht (mehr) geöffnet sein (zB Cient-seitig noch das .doc im Word offen? -> das lässt der Mover liegen).

ipvlan wurde (ab 6.10??) der "neue" Standard, da macvlan in Verbindubg mit VMs nicht stabil war.
Ja, alle Docker haben die gleiche MAC...das macht aber nur die Fritzboxen und andere SoHo-Router kirre.
 
keine Ahnung...eine dedizierte Sense hat da keine Probleme, aber die nutzt auch kein virtio.
Ja...das hatte ich befürchtet, dass Du solche Docker "brauchst"...wenn die Sense aber läuft, kann die ja auch Wireguard "nativ"....da wäre das VPN an der richtigen Stelle in der Architektur, dem Router.
 
OK, immerhin bist Du einen Schritt weiter...macvlans wurden allerdings aus gutem Grund "verbannt"...ich hatte bis 6.9 keine Probleme, aber dann ging es los.
Mit ipvlans läuft alles (ich nutze aber eben Host-Acces bewussst nicht...mein dedizierter Router macht aber auch 10Gbps und kann Wireguard nativ ... brauche einfach keine Docker damit).

Du meinst Du hast den selbst geschrieben oder ist es eine App aus dem ubuntu Repositories?
 
...einen Basis-Container (official image) für ubuntu gibt es natürlich...aber openjdk hat seine Images eingestellt. Welche Lizenz bei anderen jdks dahinter hängt, weiss ich aktuell nicht. Das/Ein Problem ist -soweit ich mich erinnere - , das zB Oracle die Verteilung so nicht erlaubt, deshalb musst Du die jdk-runtime manuell in Deinen Docker einbauen oder gar zur Laufzeit runterladen. Wie es sich mit anderen Images mit jdk (ibm, aws, ...) verhält und welche Linux-Distro dann im Image dahinterliegt weiss ich aktuell nicht.
 
Du kannst den Docker lokal bauen und lokal nutzen...oder ihn danach in den Docker-Hub hochladen und über ein unraid-template mit der URL aus dem Docker-Hub wieder "installieren". Hier sind die Grundlagen: https://docs.docker.com/develop/
 
Edit: das sieht interessant aus: https://learn.microsoft.com/en-us/java/openjdk/containers

...Das sind immer zwei Schritte, wenn Du Disks tauschen willst.
Hier also:
die/alle Parity Disk(s) aus der Konfg entfernen (Array stop, Konfig ändern, Array start -> danach ist/sind nur die Daten-Disk(s) im Array) alle/die Parity Disk(s) wieder in die Konfig einbauen (Array stop, Konfig ändern, Array Start -> fertsch) ...physisch musst Du die Disks nicht ausbauen. Aber vertausche in der Konfig nicht die (bestehende) Daten-Disk mit Parity (oder umgekehrt). Also am besten darauf achten, die Daten-Disk(s) an ihren Sots zu belassen (ganz, ganz wichtig für Schritt 2).

...Du hast es ja dankenswerter Weise auch im Bug Report thread gepostet und die Entwickler haben schnell den Fehler gefunden.
Nur falls, Du hier zuerst schaust...das ist der Fix für Dich/Dein Problem:
 
 

Ja, genau sowas hatte ich gedacht.
Mit v612(rc*) kannst Du den pool ja importieren.
Also...Lass das Array wie es ist, nimm den zpool als unraid-pool....definiere die shares, die Du auf dem Performance zpool willst in unraid, nun stelle den unraid-pool=zpool als Cache für diese Shares ein (Modus prefer oder only, damit Daten nur auf dem zpool landen/genutzt werden und nicht im Array).
Fertsch.

Nö, eigentlich nicht...es sei denn Du hast die Disks einfach physisch ausgetauscht und unraid will jetzt einen Rebuild der alten Disk auf die neue Disk machen.
 
Es gibt keinen "Downgrade" in einem Schritt
Das musst Du in zwei Schrittfolgen, nacheinander machen.
die alte DIsk aus dem Array entfernen: https://wiki.unraid.net/Manual/Storage_Management#Removing_data_disk.28s.29
Das Array wird also erstmal verkleinert die neue Disk ins Array aufnehmen: https://wiki.unraid.net/Manual/Storage_Management#Data_Disks
Das Array wird wieder vergössert ...bei beiden Schritten wird ein Parity Rebuild gemacht....den ersten kannst Du vermeiden, indem Du als erstes (Schritt 0) die Parity aus dem Array entfernst und dann (Schritt 3) wieder hinzufügst....hast Du Backups?

Parität, im Sinne von unraid, gibt es nur im Array. In einem Pool kannst Du - bei ZFS - die jeweils fürs Filesystem üblichen/möglichen Raid-Level nutzen....bei 2x1TB NVMe würde ich Raid1 nehmen....wenn Du Snaps wilst, dann ZFS.
 
Ja, siehe oben.
 
Nein, meine HDDs im ZFS Raid1 Pool gehen brav schlafen (und wachen bei Bedarf auch wieder auf )
 
Nein, siehe oben. Das Dateisystem ist egal.
Anders als bei (unraid-)Pools hast Du im Array aber kein Raid.
 
Wenn Du diese HDDs als Daten-Disks ins Array nimmst, also ohne Parity, sind bei Ausfall einer HDD die Daten da drauf futsch...die andere bleibt aber intakt.
Jede Disk im Array ist einzeln, in einem Dateisystem formatiert...jede Datei ist immer nur ganz auf einer Disk...nimmst Du eine Daten-Disks aus dem Array, kannst Du sie in einem anderen Computer oder in unraid über das unassigned Devices Plugin normal mounten und nutzen.
Es ist also kein Raid1.
Eine/Die Parität muss mindestens so gross sein, wie die grösste Daten-Disk im Array. Hast Du nur eine Daten-Disk im Array und fügst eine (oder zwei) Paritäts-Disk hinzu, so macht unraid einen "Trick" und baut nur dann einen (one-/two-way) Mirror (wie ein Raid1...aber nur dann)...dabei bleibt die Performance-Penalty des "normalen" Paritäts-systems aus....fügst Du später eine weitere Daten-Disk hinzu ist das vorbei und es gelten die "normalen" Parity Regeln.
 
-> hast Du das mal durchgearbeitet?...die anderen FAQs sind auch sicher hilfreich.
 
 
Wenn Du Backups hast oder auf die Daten verzichten kannst, dann brauchst Du sowas, wie bisher, wohl nicht.
 
nein, sie bringt in dieser Hinsicht einen Nachteil. Hat aber eben andere Vorteile...siehe die FAQ.
 
siehe oben, nein hilft nicht. Ich glaube eine 18TB schafft im Read 180-250MB/sec...das ist auch für 3-4 parallele Streams ausreichend, weil der Client/renderer ja auch puffert.
Ich würde mir da eher Sorgen um die simultane Bandbreite/die Netzwerk-Performance machen.
Wenn das wirklich nicht reicht, dann als Pool und mirrored-vdev (ZFS) bauen. Ich habe meine Medien auf einem unraid-Pool aus 2x16+2x20TB (mit ZFS)....es war einfach zu aufwendig, diese Menge zu sammeln...ich will da Redundanz  und Platz für mehr.
 
im Array ja, in einem Pool könntest Du bei ZFS diesen versuchen zu importieren.
Da einige DIsks aber in einem Hardware-Raid waren, geht es für diese bestimmt nicht anders als mit formatieren.
 
Grundsätzlich ja...Du kannst jederzeit Disks ins Array hinzufügen oder rausnehmen. Es ist aber nicht "in-place" im laufenden betrieb möglich. Das Array muss jedes mal gestoppt, (um-)konfiguriert und dann gestartet werden.
Solange Du keine Parity hast, die bei einer solchen Aktion ja neu gebaut werden müsste, dauert das aber jeweils nicht lange.
Bitte lies die FAQs oder die Dokumentation.
Du könntest auch eine USB DIsk oder eine andere, interne HDD für Backups/Zwischenspeicher nehmen um die HDDs freizuräumen. oder einfach eine  neue nehmen, die alte, gefüllte mit unassigned devices mounten (nicht wenn vorher im Hardware-Raid gewesen) und dann die Daten auf die neue im Array kopieren. Der Workflow/das Wie steht Dir quasi frei.
 
Ja, dieser Ausspruch stimmt.
Schau mal oben in den Anleitungen und auch in den FAQs...beliebt und mit guter Performance ist rsync.
Du brauchst natürlich ein Ziel-System oder zumindest eine/oder mehr externe Platte(n) (Backups im gleichen System oder am gleichen Ort aufzubewahren sind auch keine Backups).
Mit ZFS kannst Du auch zfs send machen.

Wie gesagt, bei openWRT bin ich raus. Das hat auch nix mit unraid zu tun...versuche es mal im openWRT forum.
ich gehe davon aus, dass es ein Routing/forwarding Problem ist. Du kannst mit ip-tools versuchen herauszufinden, wo / an welchem Interface der Pfad der IP-Pakete "stehen bleibt"...ping & tracsroute sind die üblichen Verdächtigen.
 

Da Du Backups hast, ist das Schnellste zuerst die Parität zu entfernen und dann die Daten-Disks in der passenden Kombi einzubauen.
Dann erst zum Schluss nochmal die Parität wieder einbauen und neu berechnen lassen.

...mal die macvlan Einstellungen im allg. Docker Setup auf ipvlan umstellen, bitte.
Das ist komischerweise kein BTRFS Prolem, sondern kommt aus ner anderen Richtung. Man sieht hier nur die Wechselwirkung.

In der 6.12rc2 habe ich alle pools auf ZFS umgestellt.

Gesendet von meinem SM-G780G mit Tapatalk

Das sollte schon so gehen...evtl. liegt es am Scanner? Alternative FTP im Scanner möglich?
 
Edit: mal die Berechtigungen im Unterordner geprüft? Diese werden von paperless-ng angelegt und gesetzt nicht von unraid.