hawihoney

I always have these problems too. All packages that need C header to compile (e.g. DBI) don't work here. And if they work I do get problems with Unraid. I don't start database related Perl scripts in Unraid. I did install a Windows VM to do just that. It's a pain but I never could find the differences in DEVPACK/NERDPACK and what Perl needs to compile.

Currently I do have 8x 16 GB RAM modules in this mainboard (= 128 GB total). CPU1: P1-DIMMA1/P1-DIMMB1/P1-DIMMC1/P1-DIMMD1 CPU2: P2-DIMME1/P2-DIMMF1/P2-DIMMG1/P2-DIMMH1 What I do not understand is " + Any memory pairs in P1, P2 DIMM slots" in the mainboard documentation. 2 CPUs & 10-16 DIMMs CPU1: P1-DIMMA1/P1-DIMMB1/P1-DIMMC1/P1-DIMMD1 CPU2: P2-DIMME1/P2-DIMMF1/P2-DIMMG1/P2-DIMMH1 + Any memory pairs in P1, P2 DIMM slots If I would like to add four more modules, where should I place them? P1-DIMMA2, P1-DIMMC2, P2-DIMME2, P2-DIMMG2 ? Many thanks in advance.

Is there a way to check if a remote Unraid server is doing a parity check and/or disk rebuild? I do have a backup Unraid server at a remote site. On my primary server I use some scripts to backup important data via rsync. With the User Scripts plugin I can check if the primary server is doing a parity check/disk rebuild. Is there a way to check if the backup server is doing a parity check/disk rebuild? Thanks in advance.

Thanks for the link. Looking great. Curious about how much weight this can handle.

What rack is this?

It's running pretty good. However, some things I changed in the meantime: The fans in the JBOD expansion boxes run nearly at full speed all the time (this powerboard has no temperature sensor) and cry like hell. But the JBODs don't need so much cooling. So I removed the two fans in the back. In addition I replaced the three fans in the fan wall with Supermicro FAN-0074L4 fans (green ones, direct replacement possible). However, I would not do that in a warm environment. The "copy large files from bare metal to VM via SMB problem" is still there. I changed copy direction and do fetch files on bare metal from VM now, always, always, always. I do not mount all these drives in Unassigned Devices. I created individual User Scripts for all mount and unmount commands. This way they don't show up on the Main page. I experienced a lot of problems if the Main page refeshed before all mount points were collected and shown. Starting the whole stuff is a manual activity: 1. Physically start the JBODs. 2. Physically start the bare metal server. 3. Do not start VMs automatically on bare metal server (starting two Unraid VMs at once did result in some problems with USB license sticks). 4. Automatically start only those Dockers (bare metal and JBODs) that don't need access to the other servers. 5. On bare metal server manually start the VMs one after another and wait til completion (JBOD web GUIs are reachable and their arrays are started). 6. Mounts in VMs to bare metal server automatically start with JBOD arrays (mount/unmout commands in User Scripts attached to Array Start/Array Stop). 7. Mounts in bare metal server to JBODs are started manually after the VMs are up and running. 8. Now start all those Dockers on bare metal server manually that need access to JBOD mounts.

I see that 16GB USB device attached to your array, but I don't think that this USB stick contains the Unraid code nor a valid Pro license ... In my case both extra USB sticks, that are counted as devices, do contain just Unraid and the license files. It's no problem for me, as you already said, but I would remove these sticks from the count of devices, if a check of the GUID and the license files reports a paid license. Consider two paid sticks (one server, one VM) with a smaller license. If the VM stick counts for the server too, it might hurt.

Funny. The unRAID USB device with a Pro license for that server does not count, but two extra unRAID USB devices with each having a valid Pro license do count? Why? There must be a reason, but I don't see one.

Thanks. But then there is something wrong. I did restart that machine 3 days ago and did not change anything. 2 Parities, 20 Data Drives, 2 Cache Drives and 2 Unassigned Devices are 26 in total - not 28. In addition I do have three USB unRAID license sticks in this server. One for this server and two for two unRAID VMs. Plus one USB TV stick. These can't count, no?

Can please somebody explain, why this server does report that 28 devices count against the license? I do count 24 ... Thanks in advance. tower-diagnostics-20190303-0914.zip

Ok, got your points. The Supermicro chassis is 60 pound I think. It's easier to move four parts (1x PC, 3x enclosure) than a single big one, sure. However, the weight of 24 drives is identical. I take them out before moving. Most people run these "home labs" in their basement without further cooling equipment. The sound is a bigger problem ...

3x HBA + 3x External Enclosure? Why not use one HBA and one 24-drive enclosure? Storage space is identical. You get cheap and used Supermicro enclosures at eBay. For that price you can get one completely filled with mainboard, CPU, RAM and cooler - just pull that out. Don't know where you are located, but I think you will get them there too. It's business grade hardware - so it's loud and heavy. Look for the "home lab" box called SC846. It should contain a BP-SAS2-EL* or BP-SAS3-EL* backplane for drives bigger than 2TB. I bought several of them from eBay. IMHO, they are build to run forever. E.g.: Located Germany, shipping free within European Union: https://www.ebay.com/itm/Supermicro-SC846E16-6GBs-SAS-Expander-4U-24Bay-920W-Platinum-PSU-846-G/283197618235?hash=item41efe4b83b:g:cLUAAOSwoM5buPmF:rk:9:pf:0 I found further ones located in Poland, United Kingdom, ...

It's DevPack. However, remove it from within the plug-in. A restart is required I think.

Do you use zlib from DevPack plugin?

Ok, I will do a test and copy a big file from VM to bare metal. But I think that will not show the real problem. Bare metal server has 128 GB RAM. IMHO part of the problem shows up here whenever the size of the copied file exceeds the available RAM of the target machine. Perhaps copying over SAS cables to SMB mount points is to fast for the target server in a VM. Perhaps something caches to much. In one of my first posts here I did point at SMBD. This process is eating up all available RAM and CPU on the target side. Perhaps that's only happening within a VM. So many questions Will test tomorrow and report back. But I bet this will work.