MAM59

Das mag Dich persönlich ja faszinieren, aber ich bezweifle stark, dass sich irgendjemand hinsetzt und Deinen Fehler sucht, wenn eigentlich schon eine Version existiert, bei der er wahrscheinlich beseitigt ist. Und wenn Du es nicht ausprobieren willst, dann musst Du entweder bis zum nächsten "stable" Release warten, oder mit dem Problem weiterleben.

Ohne Update keine Besserung...

LOOOOOOOOOOOOOL! viel Glück dann! alles über 5m ist im Risiko Bereich. >30m geht gar nicht Achte auf spontane Verbindungsabbrüche, Resets usw... Kann auch ein paar Wochen lang gut gehen, aber irgendwann sind die Phys platt und können nicht mehr gegen das Kabel kämpfen. (Ausserdem besorg Dir schon mal einen billigen Stromanbieter. Der Energiebedarf steigt mit der Kabellänge exponentiell an)

10G und Kupfer? das ist mutig. Aber wenn schon (und wenn die Kabel kurz sind), dann verzichte auf Aquantia. Dieser 107 Chipsatzs ist für Arbeitsplätze gedacht, wo nicht viel Stress ist. Bei Servern hingegen kommt schon deutlich mehr paralleler Verkehr vor, da ist Intel die bessere Wahl. Aber am Besten sind immer noch gebrauchte Mellanox X3. Rock solid und affenschnell. Gibts allerdings (aus gutem Grund) nur als SFP+ Versionen, da musst Du dann noch ein Modul hinzurechnen (wobei Kupfer immer mit Abstand die teuerste Variante ist). (Und vergiss nicht, dass mit Kupfer bei 10G definitiv Ende-Gelände ist. In ein paar Jahren ist das nur noch Alteisen)

same model does not always guarantee same size. even if, it does not mean same freespace depending on the partion layout / size You see in your example that sde1 starts at sector 2048 whereas sdg1 starts as (the usual) sector 64. So there is a difference of over 1900 sectors in net freespace. The question is "where do you have formatted sde ?" Many RAID HBAs reserve sectors for their own purposes, some filesystem types sometimes do the same. Either re-initialise the old drive "normally" or use the modified way for the new drive too. Then you will get symmetric results. Your 2nd problem is that you are still running the old 2TB drive as Parity #1! This cannot work! ALL parity drives must be "the largest cow in town". So get rid of parity #1, rethink the init of parity #2 (and then make it #1 and only) and then it might work (SHOULD work)

Thats what I thought of... Check what is in that directory, each of those scripts are executed one after the other at that time For me it is just "logrotate" and "start user scripts..." (which launches a lot of scripts from within the GUI). Dunno what you have in there so check it out and try to start each of those manually to see if the error shows up again.

waiting 20hrs wont help you I am afraid. Its just a check, it does not fix anything. You better should think about the real problem that is going on. (BTW, you might have disabled autostart, but that is not written to the stick until you do a graceful shutdown.) Take a diagnostics and show it here. maybe there is something in there that can be found.

be aware that drives from different vendors might behave differently in a hot plug slot. On some the LED is always on (to show that the cage is populated), some others flash only if there is real activity and some others might blink even if there is just a status update request from the OS or the HBA. So your flashing might be totally harmless.

kill that shfs process ( usually signal -9 is needed, the atomic bomb) 11308. Then the machine will shut down again normally. Update to 7.1-rc the problem might be fixed there already. (At least what I had was close to yours, so there is a good chance that the patch will work for you too)

Sorry, I am out with that. I never understood why somebody wanted that. Its very unlikely that somebody can break into my computer room and steal a disk. Its much more likely that I forget the password (-phrase) and am left with a working drive with unaccessible data on it.

This means your IO queue is overloaded (Data coming in is faster than writing speed, first data is buffered in RAM but after this is full, there is no way to continue. So it stalls, waits until the RAM is written out and then continues) This looks like repeating Waves, and it is normal. Writing takes much more times, not for the physical transfer only, but after the file is complete, the directories need to be updated and rewritten too. This includes a lot of additional writes and stepping. The smaller the files are, the more it will slow you down. Nothing you can do against it, be patient.

4U is usually overkill. What do you mean with "energy sufficient" ? Your current box only has a 350W PSU, it will be hard to find such a low device today anymore. And remember: 19" cases are not meant to be "ear friendly" (aka "silent"), they usually contain a lot of unregulated fans that can produce an internal storm and are as load as a starting jet engine. Be prepared to replace them to something more polite. (and usually also get rid of too much of them. there are usually 4 of them in the middle of the box, for normal hardware like yours 1 or 2 are totally sufficient)

You surely will be able to get a nice 19" case for the mainboard, maybe even with front loading hot swap bays. The problem will be the PSU, "normal" ones usually do not fit into 19" cases, especially the 1U or 2U ones because they are too flat. But you can get special PSUs for these cases too. "energy sufficient" is not the main focus for rack servers, you better move your old hardware into a new case (hopefully the fujitsu MoBo has common dimensions and screw holes).

Depends on how much you are able to suffer. "Speed" drops down to below 6Mb/s sometimes, depending on the amount of zfs disks in the Unraid array. It can even lead to a full stop under bad conditions. This is because ZFS is "clever and self-healing and self-optimizing". If there is nothing to do, it cleans up free blocks, rearranges (defrags) files and so on. So far, so good. But of course, this causes serious write operations. Normally (in a pool) you do not notice them at all because ZFS knows that it has spare time. But in an UNRAID array, the parity drive(s) sit on top and have to follow each write. And if ZFS 1 sends the head to track #34, ZFS 2 sends it to #1234 and ZFS x sends it to the moon, you can imagine what stress it creates on the parity drive (and the other drives in the array depending on the write mode that you have selected). If idle such a array may skyrocket! And of course, if YOU then want something from it, there is no IO time left... So stay away from ZFS in the array for now (they say they are working on it, but I can hardly think how this situation can be overcome by the filesystem on top of the array...)

these 75Gb can be the overhead used by the btfrs file system itself. Unlike other OS's UNRAID does not count them in as granted but shows the net allocation (others silently lower the available freespace of the drive so you never see this part of allocation)

Sure this isn't a typo ? I bet you wanted to say XFS instead of ZFS...

4:40 am is the usual time to run "daily" cronjobs. So take a look at the crontab, maybe start each of the jobs manually one by one to see which one breaks the limits. Then report back, maybe there is an easy solution to fix it.

Thats what I am used to. But that day it looped to "scanning..." over and over. Anyway, I have just retried now (in between there was a reboot or something), now "done" is back to "done". So, whatever it was, its gone now... I will report, if it shows up again someday.

This is not a question about what you want. Limetech switched license stuff recently completely, only versions >7 now are able to get a key anymore. So, unless you update, the stick cannot be activated anymore. (BTW 7.x ain't that bad anymore, give it a chance)

There is NO WAY to "maximize the speed". Whatever mode you select (and that is honored by your switch, probably NONE), a single connection always can only run at 1G max. In the more elaborate modes, MANY connections can be split among the cards (say PC#1 uses Card 1, and PC#2 uses Card 2), but still, only 1G each. (this "bundling" only makes sense if you have hundreds of clients fighting for UNRAID concurrently) So, basically, you are totally on the wrong track, shift your expectations or buy faster LAN cards.

Unless you have specific demands, just leave the CPU assignment untouched. UNRAID will dynamically use and grant cores. Just give the number of maximum cores. And, don't panic too. Cores are not fixed, they are not locked to a certain VM. The "pinning" feature is mostly used to asure that certain cores are always free (for the UNRAID OS). But again, just leav it alone. There is a "force stop" menu entry too. But be aware, if you leave the VM's setting, it is started again (at least it tries to start) Its just the version number. And, as usual, "the highest lance wins!" Have you "inserted" and configured a valid boot image (ISO file) The UEFI setup only comes up if it does not find anything to boot.

Für NPM findest Du hier dutzende von "how to setup" Threads, allerdings kommt es stark darauf an, welchen Internet Anschluss Du hast. Die Fritzbox ist recht blöd mit IP V6, und bei DSLITE gibts dann riesige Probleme...

He is not really into that python at all. He just wants to sync his e-book reader. This seems to be a buildin feature of calibre-web. Dunno why it is not working (for him?) dunno even how it can be checked. He is better advised to ask in the docker's support forum or at the calibre-web forum for this special thing.

von welchem Docker reden wir denn nun, NGINX oder NPM

Sorry, can't help you with that Kobo thing (don't even ever heard about it).