lol. Not like the GT 710 would be a bottleneck, or anything...... (sarcasm) +1 from me too.

looks like

It makes sense for his uses.

lol

no, he would be laughing in his petabyte of spinning storage, and I think he has over 100TB in fast SSD storage too

Yup, I'm planning on putting in 10Gb once I upgrade my local network to support it. my home network just isn't 10Gb yet, so I didn't pre-emptively get a 10Gb card.

Not too worried about tape drives for backup, any actually critical data is backed up in more than just this NAS, losing data on this would be annoying, but not catastrophic (again, this isn't a prod system, just a home server). The only reason I went RAID-Z2 is because having another drive die while replacing/resilvering is a very real possibility with big drives like these 10TB, especially since many are made in the same batch, so they can likely fail near each other. I'm not too concerned about the data integrity, and I would never run a system like this in prod.

I also hope the ECC RAM doesn't bite me. I would've preferred ECC, but I was (clearly) willing to take the speed trade-off. But like I mentioned, good unbuffered ECC DDR4 just doesn't really exist.

A computer that runs many virtual computers with lots of storage.

Yup, Epyc would be ideal (support for multi CPU as well as buffered ECC support (Threadripper supports unbuffered ECC, but good luck finding good unbuffered DDR4)), but at like 2-4x the price of the equivalent threadripper CPU, not to mention the more expensive motherboard as well. If you've got a lot more money to spend, Epyc is the way to go if you don't want to drop $10k+ on the equivalent Intel Xeon CPUs.

Proxmox is awesome. Even though I'm a linux guy, I would have preferred SmartOS due to the amazing ZFS support on illumos, but SmartOS is basically Intel only due to the lack of AMD virtualization extension support. With that said, being able to run lxc containers on proxmox is great due to the insanely low overhead (you can run ubuntu server with like 50MB of RAM). I just wish ZFS on Linux was a tad farther along (although it certainly isn't bad).

The bulk of it is media and general data archiving. Although worth noting it ends up being about ~70TiB usable after all redundancy and whatnot is calculated. Reliable data storage is not cheap, unfortunately.

No but I hoard/archive data.

Depends what you're using it for, and what storage solution you go with. If it's purely a NAS, and doesn't do dual duty as a virtualization server (like mine), then that's more than enough cpu/RAM to do whatever you want for storage. FreeNAS is a nice OS with a web interface that can help you build ZFS Pools, which is basically a really nice RAID.

If you are trying to do VMs as well, you can, but you'll definitely want more RAM if you do ZFS, and even if you don't, with the 6700k you probably won't want to spin up more than maybe 4-ish VMs or so total. Still totally do-able though.

In regards to BTRFS: As far as I'm concerned, BTRFS is a half-baked filesystem solution for the people on linux who were butt-hurt about the CDDL licensing of OpenZFS, and wanted a GPL-compliant file system equivalent (although BTRFS is no where near feature parity or stability of ZFS). There have been many arguments over the years whether or not CDDL is truly compatible with GPLv2 or not, and although Stallman disagrees, there are many people (including lawyers), who say it's probably fine, and people continue to work on ZFS on Linux regardless, with no one trying to stop them yet. I don't think ZFS will ever be shipped as part of mainline linux because of the licensing, but that doesn't stop it from being more supported, stable, and suitable for real-world use vs BTRFS. I think you'd be hard-pressed to find almost ANYONE running BTRFS in production because of how experimental/unsupported it is. If you do some research, you'll see just how embryonic BTRFS really is (for a filesystem. Losing data is the worst type of failure, and it still happens with BTRFS deployments). ZFS is tried-and-true, and really the only open source local storage pooling solution that is decent. I could go on talking about it for forever, but I'll save us both some time...

Why have all my storage in my hypervisor? Well that's because it's my home network, and it reduces network/hardware overhead, since I have no need for a dedicated SAN with my only goal being to share storage with the LAN+VMs. You mentioned an iSCSI box that I shared to the hypervisor, and I did consider that at one point, but as you mention, it's just unnecessary network overhead, on top of needing an entirely extra box to host the storage. I would rather over-provision a single server and have everything in one. Proxmox is simply some vm-management software slapped on top of debian, so even though I call it a hypervisor, it really is a full linux OS just running some management software, and less of a true hypervisor. I realize, and am OK with the fact that ZFS uses a lot of resources that will take away what's available from all my VMs, but that's fine with me. Also note like 90% of my VMs are actually linux containers (LXC). This combined with the fact that I don't really run a lot of RAM-heavy software like databases, redis, etc (with the exception being ZFS, of course), means that my virtualization workload is much, much, much less RAM intensive than a typical hypervisor workload. Most of my VMs (containers) use less than 200MB of RAM when running.

The other thing about primarily containers for virtualization, is it means that these VMs get native access to the ZFS filesystem/pool without ANY extra overhead. They can access data from the pool exactly like the hypervisor, with the shared kernel (NO networking stack involved). This means I can have ZFS volumes shared between VMs with literally 0 overhead (where traditionally you'd need some sort of SAN and a very good network to support this, on top of simply the general overhead and latency it takes to run all that storage over wires over a network). This allows me to take the 'micro-services' approach to virtualization, where I can basically dedicate an entire VM (container) to each major application I want to run (so my network fileshare software can run independent of my media server which can run independent of everything else, despite sharing a lot of the same volumes/files). This is great from a security perspective, and allows me to achieve a really nice isolation of services without a single massive VM, and effectively 0 extra overhead from a Storage/CPU perspective, and only a tiny bit of extra overhead from a RAM perspective (something in the realm of 50-150MB per container).

Any KVM-based VMs will still need to use something like NFS to talk back with the hypervisor to get access to any shared storage (aside from what is directly allocated to them as a VM), which has a lot of overhead. If I was primarily using Windows, or KVM virtual machines, this model of having the storage on my hypervisor wouldn't make much sense, because even though network traffic doesn't have to go over a wire to access the shared storage, it's still going through a networking stack on essentially 2 different machines (VM+Hypervisor) ON TOP OF the regular kernel calls to access that data. Fortunately, I keep these VMs that require emulated kernels to a minimum, and I simply don't share my bulk storage with them (they just get allocated whatever they need as their primary block volume, and don't interact with any other storage).

tl;dr: BTRFS is kind of a joke tbh, ZFS is battle-tested, stable, and has more features. With my primary virtualization being containers (not emulated kernels with KVM), my RAM usage is much lower than a typical virtualization workload, hence the low amounts of RAM. This is coupled with the fact that containers get native access to the ZFS pool with no overhead, so if I have one big storage pool on my hypervisor, I can share parts of it between VMs (containers) with literally 0 extra overhead, so having something like a SAN with iSCSI would be detrimental to performance, even if it didn't have any network latency, simply due to the fact that all storage requests must go through networking stacks.

Mainly containerization of all the services I want to run over a network. I.e. I have a seperate VM for my media server, network sharing software, VPN host, etc, etc. Also having a platform where I can spin up different environments on different OS is really nice as a software engineer, I can quickly test something on Windows+BSD+Linux, even going as far as to spin up a whole new VM if I need to test on a clean system.

Basically anything i want a server for, I can spin up it's own personal environment, rather than cluttering one big server running a single OS.

He could but that would be wasted money though. In a virtualization build as such, all he needs a GPU is for the graphics output while performance of the card itself has no matter

Why would he need anything more than a basic GPU?

Not a gaming rig, dude. It's a server. -_-

NAS = network attached storage.

If Threadripper had on board graphics this system wouldn't even need a discreet GPU at all.

Don't spam.

lol