tdallen

Members
  • Content count

    1170
  • Joined

  • Last visited

Community Reputation

4 Neutral

About tdallen

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  1. You have a WD Red Pro in partpicker. I've had good luck with the regular WD Reds, not sure you need to go up to the Pro (though it couldn't hurt).
  2. You'd have to give me a 1TB drive for free and pay me to put it into my server. Life's too short and quality 3TB drives can be had for $100.
  3. 1) VMs are fairly sensitive to the performance of the drive the vdisk is stored on - I'd put it on the SSD. 2 & 3) It sounds like you'd like a powerful unRAID system, and a powerful Windows VM. So, how about splitting the vCPUs 4 and 4? It's all you've got... 4) You need more RAM, 16GB would do it unless you want a Windows VM with more than 6-8GB.
  4. How much space do you want and do you want redundancy? The default configuration for 2 x 500GB would be BTRFS RAID-1, so 500GB with redundancy. You can also configure the pool so that the second SSD extends the space available rather than creates redundancy but that's more useful for older mixed size drives rather than new.
  5. Did you have this problem before you added the new switch? My guess is that extra memory won't help (though as I said early, it wouldn't hurt either). You didn't mention, but I assume the large files are being written to your cache drive. You have enough CPU and SATA bandwidth to handle both writing a large file to cache and streaming from an array drive. My guess is that network bandwidth is the issue. I can saturate a 1GB network writing files from my main PC to my unRAID server. I would have hoped that the read and write streams would have played more nicely with each other but who knows? Can you see how fast the writes are, or do you have Dynamix System Statistics loaded, or any kind of management interface into the switch?
  6. Looks like a good strategy and a good build to me. I'm not familiar with that motherboard but the stats look good. I assume you want enough processor for Plex to do some transcoding, otherwise the Xeon is overkill (but I like overkill ).
  7. Well extra memory can't hurt. Whether it will help depends on whether you are I/O bound. Are the writes going to cache or directly to the array? Do you have turbo write enabled? Are the cameras writing to your unRAID server?
  8. Hi - aside from newer hardware, is there anything you are looking to achieve or any limitations you are finding with your current setup? Also, a little more information about your current setup would help.
  9. It's hard to say. What are the remaining specs of your server? And when streaming, are you transcoding?
  10. That'll work. Make sure to read the Ryzen thread:
  11. Yes, you can install Docker to an Unassigned Device. Are you running Sickbeard as a Docker? Your PC should not be involved in moving files around in that case... Regarding RAM usage, it's probably a combination of your Dockers consuming more RAM over time and http://www.linuxatemyram.com/ .
  12. Assuming you are talking about an i7 or Xeon E3, the recommendation is to assign both Core 0 and 1 to unRAID - Core 1 is a hyperthreaded core, not a real core. And in the world of virtualization, neither the i7 or E3 are beastly - downright middle of the road at best. 14 core hyperthreaded E5's with 28 VCPUs are beastly . But the i7 and E3 have their place, since their faster clock speeds make the more suitable for performance sensitive VMs like gaming.
  13. Yes, that's correct. Generally, by the way, Dockers are preferred as applications over VMs if they are available. The virtualization there is lots lighter weight. If you are running VMs it is recommended to set aside at least one core (and it's hyperthreaded VCPU) for unRAID. You can let things be a free for all and that can work for non-performance sensitive VMs that do background processing. But for performance sensitive VMs like gaming people have had the best experience running dedicated/pinned cores for VMs under unRAID. That gets tricky if you want to run a lot of VMs and you'll see people moving to socket 2011 and Xeon E5s in that case.
  14. I think you have a pretty good understanding of unRAID so I apologize for being picky over terminology, but just in case this isn't your understanding... You don't create a server/NAS VM under unRAID. unRAID *is* fundamentally and based on a long history, NAS software. It also has the ability to run Dockers. It also includes a hypervisor (KVM) and various friendly tools to manage your storage array, Dockers, and VMs. Nope, they are unrelated. If you want a cache drive you use a cache drive (or pool). That decision is unrelated to parity, except for the fact that on older, slower systems the performance advantage of writing to cache instead of parity was pretty compelling.
  15. Before you try to figure out how to pass a RAID controller into a VM and run an OS on a RAID-1 configuration within it, I'd suggest trying the default unRAID approach - implement a cache pool of two or more SSDs in a BTRFS RAID-1 configuration and run your VMs from the cache pool. I'd recommend two things - first, spend some time in the VM Engine forum and just browse. See what kind of problems people have, and how they solve them. You'll find some highly hardware specific issues related to pass-thru, more about initial setup than ongoing use. Second, give it a try! The unRAID trial license will allow you to sort out any issues you might have with your proposed hardware. Lastly, consider this. You have data on your server. You have a 1:1 backup. You have a failure on your server. You now have one copy of your data - on your backup. It better be a good backup. I use unRAID parity protection. If I have a failure on my server the data is still there! Yes, I have 1:1 backups too - but there are benefits to a more layered strategy.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.