testdasi

You shouldn't overclock your RAM (or CPU) if you are using it as a 24/7 NAS. The risk of instability (or worse, data corruption) far outweigh any gain in performance. Get at least 80+ Gold PSU. 80+ Bronze is gonna run hoter and potentially noisier (and cost more electricity). PSU running at higher temp has a higher chance of failure => that's just physics. The 950 Pro is a NVMe drive. You will need 6.2.0 (currently in beta - which I have found to be very buggy with my VM) to use it properly (or alternatively just pass through the PCIe controller).

Win 10 but 7 and 8.1 have the same behaviour. Note that this is about the VNC virtual GPU. If passing through GPU then of course the resolution can be changed.

I think I can reliably reproduce hang similar to dAigo. Firstly, I ran "top" on the console - to get some minimal monitoring since I know the GUI will hang. Created a batch file in my Win 10 VM to move a 6GB file back and forth between 2 shares. The job will fail before finishing the 2nd copy task. It fails with "An unexpected network error occur" (see screenshot). What I observed: As long as I don't access ANY network-related thing after the error, I can actually shutdown the VM ("top" in console then doesn't show qemu-syst+ anymore - which I presume means the VM has terminated). If I do anything with the network relating to the tower e.g. open a text file on a share, the VM would hang and does not recover. Shares tested include array-only, cache array and cache-only locations. I still can browse the Internet in the VM and access other part of my network e.g. other PC's shares from inside the VM. I can still ping the tower fine from outside the VM. - ping screenshot attached There is no drive activity at all during the hang. The GUI dashboard would hang showing CPU at 100%. However, top from the console says only qemu-syst+ is using CPU and it's only about 12% and nothing else that can add up to 100%. As long as I don't exit top, top would still work and update itself. If I exit top and type any command, e.g. reboot / powerdown, the console also hangs and does not recover. After a force hard reset (actually several), everything mounts back to array fine. All of the above suggests the hang itself comes from the array. If it were the network / VM / memory etc. component then I wouldn't have been able to browse the Internet, monitor "top", access other parts of network from VM etc. My configuration: 8GB RAM, 4GB for VM Cache SSD in btrfs Single parity Array in ZFS VNC graphic No other VM / docker running during the test

I think it's in the X99 chip set. Good to know that the i218V has problems. I'll switch to my RealTek port then.

Then yes, that should work. The pass-through is usually what causes people most problems it seems. So maybe you can start with a trial license and see how things go.

You will need 2 GPU to pass through the 980 Ti to your VM. UnRAID has issues with passing through Nvidia GPU on the primary (first) slot to VM unless the default video can be set elsewhere (e.g. server motherboard with integrated graphics). As I found out recently, it even applies to having 2 GPU passthrough to 2 VMs without a dedicated video for unRAID. Easiest way out is to just buy a cheapo (AMD) GPU and use it on the primary slot. Also in your case, are you planning to keep your NAS on 24/7 (or close to 24/7). Cuz if you don't, you might actually not need unRAID. Setting up a network share would be sufficient.

Even if your monitor has a mic jack, it would be useless. HDMI is output only as far as I know. I reckon a USB soundcard would be cheapest. I treasure my PCIe slot => aint nothing going into that slot!

What was meant by this, might I ask? RAID 5 is (a lot) faster than unRAID "same-same-but-different" design. So if you are expecting RAID 5 performance, you will be utterly catastrophically disappointed. They have different pros and cons and to some (like me), the pros outweigh the speed con.

The Core X9 is super heavy.

You can passthrough usb devices by ID instead of name.

If you build from scratch, I would say bite the bullet and get ECC RAM. The way I look at it is ECC vs nonECC is like having a car with vs without air bag (yeah there was a time when airbags were an optional thing ). Crashes are (hopefully) a rare event and I have read researches which say seat belt is way more important in a crash (so in this analogy, seat belt is the parity drive). So if the data is important to you, then it's better to just pay a bit more for that extra protection. You might never actually have to utilise the memory correction functionality (like you might never be in a crash) but IF *touch wood* it happens, there is an extra layer of protection is good. Unlike car crashes though, memory corruption doesn't necessarily "crash" your system. You might just have 1 bit on your data being wrong - which you might never detect until years later when something important can't be opened because the bit is at the wrong place. Personally right now, I'm actually kicking myself for getting Asus instead of AsRock for my mobo. If I had done that, I wouldn't be stuck with 5820K and non-ECC.

HDMI is output only as far as I know. Your AV Receiver will serve as a DAC so you plug your headphones / speakers there.

what is your GPU?

Have you tried passing through scsi bus instead? See here and here. To see which of you drive is on which SCSI bus, use console command lsscsi I had a lot of problems trying to passthrough SATA controller so I gave the scsi bus a try and it seems to work for me.

try "powerdown" <-- that's the safer shutdown

You only mentioned 1 system, what is the other system? And what is your GPU?

I have a similar (and inferior) arrangement to RobJ and bubbaQ but with Crashplan. I set up a back-up share which is private and not published and set Crashplan to back up there every 3 days. Basically my rationale is if I get a ransomware attack, I should be able to detect it within that period and switch off Crashplan.

Can I still mount an array-unmountable but repaired drive outside of array (via Unassigned Devices) though? So the idea is to run repair => mount it outside array => copy all the data onto a spare HDD (also mounted outside of array) => investigate and fix any issue => put the dropped drive back on array (assuming no issue with the drive) => format => copy data from spare HDD back to the mounted drive. Would that work? I reckon that would still be faster than trying to rebuild.

Your motherboard (Asus Rampage X99 chipset) doesn't have on-board video. I just realised, you have all nVidia GPU. I think unRAID has problems passing through nVidia card on the first (primary) Pcie slot if that's the only video output. I never thought that would cover cases with 2 GPU both passed through at the same time. Read this Unfortunately I think the only fix is to buy another cheap (AMD) GPU to put on the primary slot => and there's no guarantee that would work either. But for £25 or so, I'm guessing I personally would try to get a cheap Asus HD5450 to plug in and see.

Can I just run the repair tool without rebuilding? Just thought - let's say I copy over a not-so-important file and the drive drops - presumably would cause an error prompt. Then I notice a disk has gone unmountable. Since I know the lost file isn't that important, should I simply run the repar tool instead of waiting for 2 days worth of slow rebuild?

Question 1: What would unRAID do if you write to a file that is already on the array? Does it write straight to the array or does it make a copy in cache first? Question 2: What if the cache is full? As far as I know, if cache is full, unRAID will write straight to array - negating any defense. Perhaps a "plug-in-able" thing to do is to have Cache-only shares linked to Array-only shares and have the plugin does the moving (since as far as I know, plugins have full access to all shares). The complication is how to see all the content in Cache + Array. Or things would be a lot easier done at LT code level. Perhaps have a "protected" flag for shares which turn cache on and disable writing if cache is full + "copy-on-write" kind of flag. The complication is with how to deal with free space and stuff. Nothing is easy. *sigh*

Is it slower because <8TB drive slow down the parity check simply because they are <8TB Your <8TB drives are just slower e.g.5400rpm Too many drives cause a bottleneck on the controller [*]Other reasons? I can't get my head around how mixing drive sizes would slow down the speed.

Enable.

How can that be done?

Tools => Diagnostic Log.