DataCollector

same issue. Is it possible to change it, that the update will not be shown, wehn the system ist not compatible? I use unraid 6.11.5 on 2 different PC. Since yesterday on both of them the Plugins-Section shows "Update". But when I try to use it, the process tells me: plugin: updating: disklocation-master.plg plugin: installed Unraid version is too low, require at least version 6.11.9 Executing hook script: post_plugin_checks Why does it show me a possible update, when it is not possible? And to top it of: even 'fix common problems' does now mention this plugin in the warning section.

Wenn ich dahin wechsele, erhoffe ich mir in meinen Multi-Device Pools einen stabilen Betrieb. BTRFS ist ja aktuell (pre 6.12) ja die einzige Möglichkeit mehrere Datenträger im Pool als einen zu benutzen und bei BTRFS wird ja immer mal wieder von Ausfällen und Problemen berichtet. Ich bündele in diversen Pools verschiedene SSD oder auch Festplatten, bisher mit Raid0 oder auch Raid5.

Das sieht mir nach einem (oder besser 2) Scrollbalken aus und könnte damit zu tun haben, daß sehr viel Text und Symbole nebeneinander in die Zeile gequetscht werden. Gerade im Dashboard kam ja auch noch das Schloß-Symbol dazu damit man es umsortieren (oder eben blocken) kann. Übergangsweise könntest Du mal den Arrayfüllstand ausblenden. Ich vermute dadurch wird mehr Platz geschaffen und die Scrollbalken verschinden. Ich bin noch bei 6.11.5 und auch schon da (und in vorherigen Versionen) hatte man die Tendenz mehr in eine Zeile zu quetschen, als der Bildschirm/Auflösung her gab. Da hat man sich dann aber dazu entschieden Symbole automatisch auszublenden (was mich massiv nervt, weil genau die Symbole verschwinden, die ich nutzen will).

Dann würde ich sogar nur einen USB2.0 Stick nehmen. Der schluckt idle vermutlich sogar noch weniger als eine Platte. Es ging darum daß kazino43 ZFS im Array will, weil er sich davon mutmaßlich Trim verspricht. Und auch wenn ich weiterhin zweifele, daß ZFS im Array Trim ermöglicht ist es Möglich dort einzusetzen und dennoch seh ich nicht, warum es als Singledisk System unsauberer sein soll als ein anderes Dateinsystem auf einer Singledisk. Ich zitieremich selber: "Deshalb ist unraid stromsparender als normaloes Raid (beispielsweise Raid5) weil dort immer alle Disks benötigt werden um eien Datei zu lesen/schreiben." Im Unraidarray liest man aber in der Regel eien datei von einer Disk und wenn man schreibt schreibt man eine Datei nur auf eien Disk und die Parity. im schlimmsten Falls laufen von meinen 26 Festplatten im array also 3 beim Schreiben an. Ein ZFSraid mit 26 Festplatten braucht wieviele laufende festplatten um eien Datei zu schreiben? Daß sie idle in den Spindown gehen ist ja nicht ausgeschlossen.

Was willst Du hören? Die größt maximale Anzahl ist leider eine unbekannte Zielgröße. Wenn Du ein Multi Epic System mit einigen Dutzend TB Ram zusammen stellst wird mehr drin sein, als mit einem Celeron und 4GB Ram. Willst Du also größte Anzahl mußt Du auch klotzen, weil es immer einen mehr geben kann (solange die Software nicht limitiert und die Container sich idle besser die vorhandenen Ressourcen teilen). Debian Bullseye ist nur ein OS, welches von idle bis hin zu massivsten Berechnungen oder Datenverkehr so einiges kann. Und dementsprechend kann es sein, daß die Container so gut wie keine Ressourcen benötigen, bis zu massivst ausgelastet werden. Oder sollen die debian Container nur dem selbstzweck dienen zu beweisen, daß man 250 Container laufen lassen konnte, auch wenn keiner davon wirklich etwas macht? Ich schätze, Du wirst etwas präziser werden müssen, was Du wirklich willst oder zu brauchen glaubst.

Nur wenn man Parity einrichtet. Aber auch ohne Parity muß es nicht gleich unsauber/defekt sein. Sollte zfs auf einer single Disk nicht die selbe Qualität erreichen, die ein normales Filesystem auf einer Singledisk, ist es defekt. Sollte auf der Disk ein Problem auftreten, würde das problem auftreten, egal ob man fzs oder xfs oder BTRFS oder NTFS oder FAT oder sonst etwas nutzt. Nur bietet eben ZFS, wie auch BTRFS die Möglichkeit durch zusätzliche Disks (wenn gewünscht) Redundanz zu erreichen. Aber da ZFS im Array eben nur SIngleDisk kann, weil das Array eben nur einzelne Datenträger benutzt bedeutet es nicht, dass die Daten auf einer Disk mit zfs generell unsicherer oder 'unsauberer' sind als die Daten mit xfs. Die redundanz ist bei SingleDIsk egal, weil es sie nicht gibt. Warum ist ZFS als Singel Disk unsauberer als jedes andere Dateisystem, welches eine SIngleDisk verwaltet? Das sind zwei komplett unterschiedliche Konzepte und das mit Absicht. Das unarid Array (egal ob mit oder ohne Parity) benutzt für Dateien imme rnur genau eine Datenfestplatte, damit alle anderen schlafen können. Deshalb ist unraid stromsparender als normaloes Raid (beispielsweise Raid5) weil dort immer alle Disks benötigt werden um eien Datei zu lesen/schreiben. ZFS benötigt ebenfalls (fast) alle Disks gleichzeitig und ist somit nicht das, was das Ziel un der Nutzen eines unraid Arrays ist. Wenn DU ein permanent laufendes Array haben willst, lege es als Pool an oder überlege ob unraid wirklich das ist, was Du willst. Überlege Dir, ob Du wirklich ein "un"raid haben willst oder ein (zfs)Raid. Diese Frage kannst Du Dir stellen, für jemand, der möglichst geringe Ausfallzeit haben will, macht es Sinn. Wer mehr will, ist vielleicht bei unraid nicht richtig aufgehoben. Meine Hardwareraidkontroller schaffen weit mehr, schlucken aber auch weitaus mehr (Strom). Dann lass die Parität doch weg. Dann brauchst Du kein preclear und hast höhere Schreibperformance. Ist doch ganz einfach.

Die schnellste (und ausreichend große) Disk/SSD sollte Parity sein. Wenn das eine Festplatte ist, sollten die SSDs nicht ins Array, sondern in Pools unterstützen. (Cache oder Extraspeicher).

Das wäre mir schon zu lange (langsam). Deshalb sichere ich die Verzeichnisse/Shares, die für VM/Docker notwendig sind einfach von der SSD auf eien andere SSD (Zwischenlager). Später kann dieses zwischenlager dann in aller Ruhe auf das Array oder wohin auch immer kopiert/verschoben werden. (Meine W10 VM ist so ca. 300GB groß).

Wer ZFS nutzen will, wird sich damit wohl etwas genauer beschäftigen müßen. Und dann wird man eben seine Gründe dafür oder dagegen finden. Meiner (bisher kaum ZFS kundigen) Meinung nach reicht im Array xfs (enc) aus. Stabil im Sinne von vergleichbarem Raid1: klar, dafür opfert man aber eben Kapazität. Sauber: warum sollte es auf einer einzeklnen Disk unsauber laufen? Und dagegen hilft ja die unraid Parität. Ich sehe deshalb da noch kein Problem. ...wenn man die unraid Parität und die obligatorischen backups komplett ignoriert. Einfach mal den normalen Anwendungsfall von unraid im Auge behalten.

Weißt Du schon, wie Du die in Summe 8 SSD anbinden willst? SATA, NVME, SAS? Bisher unterstützt unraid im Array kein Trim. Dass der Grund dafür BTRFS oder XFS sein soll, sehe ich nicht, da in den Pools ja auch nur die beiden Systeme neu zur Verfügung stehen. Ohne Trim kann man bei einigen SSD Performanceeinbussen haben. Heutieg Marken SSD haben aber ein GarbageCollectionverhalten, welches da dennoch gute Arbeit leistet. Aber mit Trim wäre es besser. Auch deshalb ist es sinnvoll SSD ein Pools zu stecken. Ein paar leute nutzen ZFS, weil es einige Vorteile hat und diese bei SSD sich nicht ganz so negativ auf den Strombedarf auswirken wie bei Festplatten, die dann länger laufen. Daß diese Leute es nur wegen Trim machen habe ich noch nirgends gelesen. Ich habe noch nicht gelesen, daß Trim im Array überhaupt kommen soll. Aber ich habe die Releasenotes zu den neuen RC1 und RC2 auch erst heute morgen überflogen. Meinem bisherigen Informationsstand nach ist es nur so, daß Trim in den Pools geht. Dann lass das Array doch links liegen (nur mit einem Dummy USB Stick einrichten) und steck alle SSD in entsprechende Pools ab unraid 6.12 (aktuell Rc2) eben auch in ZFS Pools. Welcher Grund ist denn das überhaupt? Welchen Vorteil bietet Dir ein SSD Only Array gegenüber SSD Only Pools (ggf. Mehrzahl)? Ich nutze aktuell in meinen unraidsystemen 4 oder gar mehr SSD, aber eben in Pools. Zu rZeit noch SIngle als xfs und wenn es mehrere zusammen sein sollen als BTRFS, weil ich anders die nicht in Pools kombinieren kann. Sobald ich ZFS halbwegs verstehe werde ich vermutlich die BTRFS Verbünde auf ZFS wechseln. Wenn Du eine groß genuge Festplatte hast kannst Du die Daten auch darauf kopieren. 4+4+4+2+2 TB = 16 TB. So große (und größere) HDDs gibt es zu kaufen. Und wnen irgendwann dein unraid Datenschatz größer als die aktuell größten 22TB Festplatten wird, kannst Du ja auch einen Verbund von Festplatten zurück greifen. Ich sichere gerade einen 36TB Nutzdatenverbund auf ein ext. raid5 (Qnap TR-004 mit 4x 12TB Festplatten). Ich sehe irgenbdwie keinen Grund für Deine Bedenken/Frage. Warum sollte das Transferieren von Daten nicht möglich sein? Das ist doch das A und O eines NAS und der Freigaben/Shares. Irgendwie verstehe ich bisher Deine zugrunde liegenden Gedankengänge nicht. Hast Du irgendwo gelesen, daß je Trim im Array möglich sein soll? Das muß ich dann iorgendwie/-wann/-wo übersehen haben. Im Array sind laut dem, was ich zu RC1 und RC2 gelesen habe nur Single Disk ZFS Konstellationen möglich. ZFS Raid-Arrays sind für Pools vorgesehen. Entweder habe ich das komplett überlesen und/oder falsch verstanden oder Du hast vielleicht da einen anderen Wissens-/Vermutungsstand. Nimm für SSDs Pools, wie mutmaßlich die Mehrzahl der Leute mit unraid. Unraid war gedacht und ist wohl auch weiterhin hauptsächlich als NAS für große Kapazitäten (und darauf deuten bis zu 28 Datenträger im Array ja hin) vorgesehen. Ja, man kann es auch mit SSDs machen, aber da Festplatten bei großer Kapazität immer noch preislich attraktiv sind, sind SSD im Array eher zweitrangig. Mal eine ganz kätzerische Frage: Wenn es nur wirklich 'winzige' 16TB Daten sein sollen: Warum nicht 2x 16TB HDDs (Daten+Parity) und eine große Cache SSD? Das dürfte billiger sein, bei geschickter Konfiguration auch gleich bis sogar stromsparender als ein durchlaufendes ZFS Raid und weniger Datenträgeranschlüße benötigen. 16TB SSD Kapazität +4Tb SSD Parity schlagen aber dennoch ein größeres Loch in die Kriegskasse als 2x 16TB HDD. 16TB sind aber doch schon (noch) recht viel = teuer, wenn es um SSD Kapazität geht, auch, wenn man sie aus 4 und 2TB Einzelkapazitäten zusammen stückelt.

Wobei mit 6.12 auch kein Trim im Array mit btrfs oder xfs abzusehen ist. (ich habe davon zumindest nicht sgelesen). Dass ZFS im Array Trim unterstützen würde ist mir ebenfalls noch nicht unter gekommen.

Halleluja, das abgebildete Gerät schein 6 Displayport Anschlüsse zu haben (2 in Normalgröße und 4 in Minibauform). Kann die CPU das überhaupt? Ich dachte die pre 8Gen CPUs machen maximal 3 GPU Ports mit und selbst die neuren CPUs sind meist mit max 4 GPU-Anschlüssen benannt. Ist da eien extra Grafikkarte drin? Das würde vielleicht bedeuten, daß möglicherweise der gewünschte PCIe Adapter auch schon drin ist.

Parity im Array bedeutet, daß alle Festplatten bei Checks gleicheztig laufen. Da ist es zu empfehlen die Festplatten nicht zu weit in der SATA/PCIE Bandbreite einzugrenzen. Ich rechne pro moderner Festlatte ab ca. 10TB mit rund 250MByte/s. Das würde ich pro Port rechnerisch dann nicht unterschreiten wollen. Zur Verdeutlichung: an einem PCIe3.0 x1 Anschluß (=ca. 1GByte/s in Summe) sehe ich 4 SATA Ports somit noch als gut brauchbar an. 5 oder mehr Ports an 1GByte/s würde schon bei gleichzeitiger Nutzung die geschwindigkeit pro Port auf nur noch ca. 200MByte/s senken. Das wäre bei mir ein 'No Go'. Bei ZFS laufen eigentlich beim Schreibzugriff alle enthaltenen Festplatten, somit ist das vergleichbar kritisch zu sehen. Außerdem ist ZFS eigentlich in den Pools vorgesehen. Da ist der 'in unraid klassiche Begriff von Paritätsfestplatten" aber nicht so angedacht. Ausnahme: Soweit ich gelesen habe sind Single-Drive ZFS Devices im Array vorgesehen. Redest Du von dem unraid Array oder Pools? Ich betreibe 26 Festplatten im Array (24 Daten + 2P ; XFS enc). Bei einem Paritycheck erreicht jede Festplatte nur das maximal mögliche ihrer eigenen Geschwindigkeit (ich erwähnte schon die ca. 250MByte/s, die ich als notwendiges Peak ansehe). Natürich erreicht das Array dann lesend im Paritycheck so um die 6 GBYte/s, doch das ist eben nur, weil das Array überall nur linear/sequentiell die Sektoren liest und nicht eine losgische Datei abliefetn muß. Sobald man im klassichen unraid Array eine Datei aufruft liegt diese Datei eben nur auf einer Festplatte und somit limitiert hier die Festplatte. Bei ZFS ist es ja eher Raidähnlich und dort arbeiten dann mehrere Festplatten gleichzeitig, was einmal im Array wieder das Problem der SATA Portlimitierung bei Überbeanspruchung der Anbindung (PCie) auslöst, wenn man so konstruiert/aufbaut und andererseits ist der für unraid gewünschte Effekt des Tromsparend durch schlafende Festplatten futsch. Wenn man also eigentlich nur ein klassiches Softwareraid (hier mit ZFS) aufbauen will und die Stromsparvorteile von urnaid über Bord wirft, weiß ich nicht ob man da wirklich dann unraid für nehmen sollte. Bei einem reinen SSD Array mag das noch etwas bringen, weil sich SSD selber sehr schnell schlafen legen könne und nicht erst auf ein Spindown des OS warten müssen, aber bei Festplatten bin ich skeotisch ob das wirklich dem Sinn und Zweck von unraid entspricht. Und genau das machen die PCIe Switche nicht. Nifurcation ist dei permanente Trennung eines Slots auf mehrere unterbereiche ohne Wechsel der Zuordnung im laufenden Betrieb. PCIe Switche arbeiten aber vergleichbar einem Ethernet Switch, der die Lanes/Wege nicht fest in einer Richtung schaltet, sondern sich die enthaltenen Datenpakete ansieht und diese zielgerichtet dynamisch verteilt. Dann würde mich das Ergebnis interesseiren, weil man dann ja das Ganze auch noch irgendwo im Gehäuse pklatzieren/fixieren muß und sich dann einige gutzend SATA Kabel etwas 'störrisch' auswirken können. Da würde ich dann bisher erst einmal zu einem normalen M.2 ASM1166 Kontroller raten. Mit dem ASM1166 sind bis zu 6 SATA Ports gut für Festplatten nutzbar. Sehe ich auch (bisher) so. Vermutlich hat Dein Mainboard ja auch noch ein paar OnBoard SATA Ports, wodurch Du dann zu sogar in Summe zu mehr als 6 SATA Ports kommst und es dann weitaus energiesparender gestalten kannst, als wenn Du von M.2 PCIe x4 über Riser zu PCIe x16, dann auf PCIe Switch und dann mit mehreren SATA Kontrollern zu SATA konevrtierst.

Fertige mindestens ein Backup Deiner Daten an, lösche Dein Array, leg es neu mit der leeren 2TB DatenSSD und einer 2TB großen ParitySSD an, spiele das backup zurück. Beachte unraid hat so seine Einschränkungen mit SSD im Array. Pech, dann kannst Du das so nicht nutzen. Die Paritätsdatenträger (jeder!) muß mindestens so groß sein, wie der größte DatenDatenträger im Array. Wenn Du also beispielsise eine 1TB Paritätsfestplatte1 und eine 500GB Paritätsfestplatte2 hast, darf der DatenDatenträger maximal 500GB groß sein.

Defaultwert ist (meiner Erinnerung nach) 0. Auch hier sollte ein Wert stehen, der größer als die größte zu übertragende/speichernde Datei ist.