To add to this….ive added a layer of protection against accidental deletion and dumb fingering by making each year of my photos archive into a separate zfs dataset. Then each year I set each dataset to read-only and create a new one.

Manual, but effective enough. I also have automatic snapshots against dumb fingering, but this helps against ones I don’t notice before the snapshots expire.

I did (am doing) something very similar. I definitely have issues with my indexing, but I’m just ordering it manually by year/date for now.

I’m doing a little extra for parity though. I’m using 50-100gb discs for the data, and using 25gb discs as a full parity disc via dvdisaster for each disc I burn. Hopefully that reduces the risk of the parity data also being unreadable, and gives MORE parity data without eating into my actual data discs. It’s hard enough to break up the archives into 100gb chunks as is.

Need to look into bacula as suggested by another poster.

Yes. Your machines would have one main IP address, and one virtual IP address that would be assigned to either machine depending on the priority or health check status. That IP can be on the same physical interface, or a separate one. It’s very flexible, pretty standard config for high availability setups.

Keepalived to set up a floating IP between two proxy hosts. The VIP is where the traffic points to, the two hosts act as active/passive HA.

I think the universal consensus is that outside of a very specific use case: multiple VDI desktops that share the same image, ZFS dedupe is completely useless at best and will destroy your dataset at worst by causing to be unmountable on any system that has less RAM than needed. In every other use case, the savings are not worth the trouble.

Even in the VDI use case, unless you have MANY copies of said disk images(like 5+ copies of each), it’s still not worth the increase in system resources needed to use ZFS dedupe.

It’s one of those “oooh shiny” nice features that everyone wants to use, but will regret it nearly every time.

Neat……but dnsdist would be my go to tool for doing this instead. It’s actually built for it, has more options, and probably doesn’t have as many host networking docker deployment limitations.

Big elk stack?

Just an A record, you just need the domain query to resolve to your IP.

Yes, but it’ll likely still be faster, just not as dramatically. Half of 4-94x is still 2-47x faster.

http://vgmusic.com/

3-4 days easy. That’s with turning on all the gps/heartrate/iOS sync functions tho. Turning off the gps and heart rate monitor and I’m sure I could get 7 days easy, and turning fewer notifications I have no doubt it’s go 2weeks.

My bad it’s actually https://banglejs.com/

Tried https://bangle.js? Loving mine so far. Edit: my bad https://banglejs.com/

“Both sides”

“Vote third party!”

Wtf seriously this isn’t the same thing remotely but the arguments used are.

Where has that been all my life!

I’ve always found the documentation around virtio-GPU and virtgl very lacking, and have never gotten them working. Would love to get pointers if anyone has a good source.

I don’t see any performance differences with the vgpu actually. I have more performance bottlenecks with the CPU, and my RAM isn’t the fastest, so I think I’m more CPU limited. Benchmarks I have run that are GPU focused seem to show little to no difference from what the physical card would do.

Yeah unfortunately. 20xx is last generation supported so far via the patch, not sure if support for later cards is coming or not.

No, but I think you’d have some problems. Only the host has access to the actual DisplayPort outputs, all the vgpus have virtual displays, I don’t think there’s a way to make them use the physical out.

Sure, but you’ll get diminishing returns most likely as consumer hardware doesn’t really have the resources to scale that way very well if all the VMs are running demanding apps simultaneously.

Even for something like 4 VMs that just do NVenc, there are limits for how many streams the GPU can do. I think there’s another patch that lets you raise that, but at some point you’ll run out of resources quick. Even powerful consumer gear isn’t really designed to be used by more than one user/app and it starts to show the more you virtualize and split those resources.