MAM59

Members
  • Posts

    616
  • Joined

  • Last visited

Converted

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MAM59's Achievements

Enthusiast

Enthusiast (6/14)

73

Reputation

18

Community Answers

  1. 2,5G is really evil. Dont buy such castrated switches!!! In reality 2,5G is just 10G with 1data+3pauses. Your Unraid thinks it can do full 10G but of course, it fails. You may try to activate Flow Control for the 2,5G ports in your switch, this could pace Unraid out and the connection maybe stable then. But you should better buy a real 10G switch, much less stress!
  2. lemme guess, you have a cache disk ahead of the array?
  3. nee, nu gerade nicht mehr :-)) Es gibt pro Platte/Filesystem immer nur EIN Root Verzeichnis... das heißt dann auch "/".
  4. First of all: the 100% CPU are usuall just 0% real CPU. This is just a display problem of UNRAID, it counts in the "waiting for IO" time of that thread. What happens is that the disk cannot keep up with the writing speed, RAM cache runs full and the OS halts the thread and writes out the buffers slowly. You may install "tipps & tweaks" plugin and play a bit with the values of 'vm.dirty_background_ratio" and 'vm.dirty_ratio". Read the help entries for them then try. You may find a setting where transmission maybe slower a bit, but smoother (without blocks). But, in any case, its harmless and at the end total transfer time is almost the same again, whatever values you are using. But it "feels" better without pauses 😁
  5. Leichte Korrektur: Jedes gefundene Verzeichnis im Root-Verzeichnis. Ansonsten würde das zu wenig Shares ergeben 😜 (ok, lassen wir die Rosinenpickerei 😘)
  6. Nö, ist gehoppst wie gebügelt (also: total togal!) Unraid nimmt einfach JEDES gefundene Verzeichnis und legt dafür automatisch einen Share an. Allerdings hast Du Dir das Leben wieder unnötig schwer gemacht, es wurde doch mehrfach darauf hingewiesen, dass der erste Pool "Cache" heißen sollte. Nur dann werden Freigaben wie appdata, system usw. automatisch dort erzeugt und die Shares korrekt konfiguriert. Dann wären Docker und VMs jetzt schon bereit... So musse nun alles von Hand machen. Und verzichte auf die ms bei "user", ich hab das damals auch gemacht in gutem Glauben. Erwies sich aber als permanente Stressquelle, denn jeder neue Docker kommt vorkonfiguriert mit user und wenn man dann nicht dran denkt, die Pfade alle von Hand anzupassen (VOR dem ersten Start), dann landet alles auf der falschen Platte und man hat echt Arbeit, alles wieder einzusortieren. Fällt erstmal gar nicht auf, da alles läuft. Nur auf dem Backup fehlen diese Docker dann leider hinterher, weil sie nicht im richtigen Pfad sind...
  7. maybe you need to manage your switch before it passes on the traffic? (some switches have dedicated or preconfigured ports for management or something. try to plug UNRAID into a different port (or try the same with the port your router is connected to))
  8. Hey, er hat da nur 2 NVMes drin, wie groß mag da der Overhead sein? 0ms fürs "Aufwecken" und 0,0001ms für Suchen in den Directories... Dein Einwand ist korrekt bei schlafenden, normalen, Festplatten aber bei seinem Aufbau ist da gar nix.
  9. I still don't see your problem. 1&2 are started. Btw, it is perfectly normal that "Autostart" works after a reboot but not after a manual start of the array. What are you expecting to happen???
  10. Dann geh da auch wieder hin 😁 TRIM ist eine interne Funktion der Festplatte. Hat gar nix mit dem verwendeten Dateisystem oder OS zu tun (das sagt nur: MACHMA! und sie macht, oder nicht). Im Prinzip ist TRIM eigentlich transparent fürs OS/Filesystem. Es wird der Platte mitgeteilt, welche Sektoren nicht in Verwendung sind. Die Platte entscheidet dann, was damit zu tun ist. Manche werden gelöscht und "dem freien Pool" zugeordnet, manche werden als "zu alt" erkannt und ausgesondert usw. Es kann dabei zu Verschiebungen auf der Platte kommen, die kriegt das OS aber nicht mit. Dabei passiert normalerweise nichts, aber es kann auch vorkommen, dass die Platte sich "defragmentiert". Das würde dann auch Auswirkungen auf die Daten haben, und somit eine Neuberechnung der Parität erfordern. Und da die Platte davon nix sagt, hat UNRAID aus Sicherheitsgründen die TRIM Funktion für Array Platten verboten. Mit defekter Parität wäre keine Datenwiederherstellung im Fehlerfalle möglich. Keine Ahnung, noch nie probiert und ich habe auch keinen Bedarf dafür. Das hilft Dir auch nur, wenn Du mehrere Platten in einem Pool betreibst, die dann zusammengefasst werden zu einem RAID Array (bei 2 = Spiegelung, ab 3 dann RAID mit Parität). Ich hab ja UNRAID, damit ich KEIN RAID brauche 😜 Ich bleib bei simplen XFS. (allerdings hab ich auch ein (derzeit) 54Tb Array mit normalen Platten, bei dem ich problemlos und ohne Umkonfiguration noch 12*18Tb nachwerfen könnte.., Und dabei kommt das das eigentlich geniale Feature von UNRAID zum Tragen: ich brauch mich um die Datenverteilung nicht zu kümmern. Wird eine Platte voll, macht UNRAID von alleine woanders weiter. Von aussen sieht ein Share aus, als wenn alle Dateien gemeinsam in einem Verzeichnis wären, in Wirklichkeit können sie über viele Platten verteilt sein. Somit gibt es nie den Druck: "meine Filmplatte wird voll, ich muss ne grössere kaufen", sondern man wirft irgendwas nach, was gerade rumliegt oder man kauft irgendwas, was gerade so billig ist.) In wie fern? BTRFS scheint ab und zu dazu zu neigen, sich selbst zu zerstören. Zumindest gibt es darüber hier reichlich Berichte. Ich brauch son Stress nicht, zumal ich wie erwähnt gar kein RAID in den Pools haben will. Also: play it safe and sleep tight... Jo, damit vermeidest Du eine Umleitung und sparst somit etwas Zeit beim Zugriff. Das ist aber zumindest meist nur ein messtechnischer Gewinn ohne Signifikanz in der Realität. Ja ok, DAFÜR sind die unassigned Devices nötig und gut. Aber von denen hast Du bislang nix gesagt.
  11. since the people here are not very good in "bone-throwing" or "bug guessing", it would be advisable to supply diagnostics too...
  12. WHAT should happen? You have turned off Autostart on the 3rd VM, so why did you expect it to be started???
  13. BTRFS + Encrypted ? hmm, sowohl etwas gefährlich, als auch etwas paranoid :-))) Ich hätte xfs ohne Fisemattenten genommen. BTRFS is etwas "anfällig" und ab der nächsten UNRAID Version gibt es stattdessen (nee, "zusätzlich") noch zfs zur Auswahl. Um in Zukunft zerlegte Dateisysteme zu vermeiden, solltest Du vielleicht nochmal von vorne anfangen und auf BTRFS verzichten... Der erste Pool heißt automatich "cache". Da werden dann auch automatisch Docker und VM Dateien angesiedelt (und verbleiben auch dort). Du musst also nix tun. Beim zweiten Pool kannst Du den Namen frei vergeben. Du brauchst auch kein Unassigend Devices Plugin. Das ist nur dafür da, Platten zu verwalten, die weder im Array noch in Pools sind.
  14. Forget the card or the motherboard, get a better cable instead. They SAY you can use normal CAT 6(a) cables, THEY LIE!!! 99,9% of the common "lost link with no apperent reason" bug are made by the cables. (this problem is not related to UNRAID only, all OSes suffer from it)
  15. Du brauchst gar kein Array, wie @Dexter84 schon sagte, ein "Cache" ohne Cachefunktion reicht aus (alle Shares auf "Nur Cache" stellen, bzw auf "Nur NameVonAndererNVME" ) Update: ooops, war gelogen, sorry. Ja, son Dummy muss her, sonst kannst Du auch keine VMs und Docker verwenden....