/hsg/ - Home server general

>Odroid C2
why would use use personal wiki
mail server - you have proper records, its not advisable to run mail server on your home connection, some ISP can ban you
sql server for what purpose?
and what software do you use as router
desu im surprised u managed to run so much shit on this small of devices, and not drop packets

How do you feel about servers that do more than one thing?
Can the NAS also be the Mumble server?
What's the right way to go if you only have one system to make a server out of?

Why not ESXi and make a bunch of VMs?

>why would use use personal wiki
As some sort of digital whiteboard. Having useful resources and links all on one page, is amazing for projects.

>mail server - you have proper records, its not advisable to run mail server on your home connection, some ISP can ban you
Mine is fine with it, I checked beforehand

>sql server for what purpose?
Both the mailserver and wiki use SQL.

>and what software do you use as router
A dash of Iptables magic

>desu im surprised u managed to run so much shit on this small of devices, and not drop packets
It's not even close to it's limit. I'm running out of shit to do with it. Pic related

>But if I am correct, he sells the data he gather for a site, to get a premium account or some shit like that, would like details too
You can 'sell' the data to either Flightaware, or flightradar24.
Both give you a premium account if you do.

I used mediawiki, but pretty much any will do.
I've seen dokuwiki suggested, t doesn't use SQL which was a dealbreaker to me. but if that doesn't apply to you, it works too.

>>Steam bot(thx (You))
np bro

Attached: 1498620419324.png (629x80, 5K)

rough cost estimate?

If you were to buy it on ebay? Uhhh, no idea.

I'm ~$2000 into everything. The AP's, Dell switch, and drives in the T410 were purchased new.

neat, what services do you run?

thanks user, i take it u use odroid instead of pi cause of the ram and lan speed?

whats your setup is like, did you install everything manually or?

Does btrfs still blow up if you put VM images on it?

I don't expect heavy random writes, I just want some scratch VMs for browsing sites I don't trust and trying out different distros and stuff like that.

Attached: 1513792918136.jpg (953x953, 148K)

Skype for business, exchange, SharePoint, team foundation server, Plex, and some testing VMs.

cool someone else doing S4B. I start a new job in a month where S4B & Exch is my main focus. you doing anything with calls? About to setup 3CX/PBX in a Flash and integrate google voice + voip phones at home

just disable copy on write for your images/folder containing images.

chattr +C /var/lib/libvirt/images
chattr +C /var/lib/libvirt/images/*

would using a container cryption like dm-cryp or luks reduce ZFS reliability?

Since it's making a layer between the hardware and the filesystem.
I understand file based encryption would allow checksums but do containers?

zfs has built in encryption so there's no reason to use encryption below, but the only "problem" (aside from pretty much throwing away all of zfs's benefits from not having actual hardware to work on) would be more overhead to encrypt (and possibly compress if btrfs) twice.

I'm using zfsonlinux which I assumed doesn't have native encryption yet.

Well yeah, I specifically want to not do that, because that stops said files from being checksummed and having all the self-healing and magic resistance to flaky drives. And that stuff is the only reason to use Btrfs in the first place, if I was willing to live without checksums I might as well just use ext4. I know ZFS will put up with having VM images on it, checksums and all, but I was hoping to use Btrfs to avoid dealing with the hassle of an out-of-tree filesystem.

I read on the Btrfs wiki that VM images are supposed to not cause problems in the modern autodefrag era when you use Btrfs with vaguely recent kernels. But I was hoping someone here had gone ahead and done it, without disabling CoW, and could say either "Seems to work for me" or "exploded in my face"

I don't think it won't work, maybe just use raw images instead of qcow2 or whatever "snapshot-able" proprietary disk image type with copy on write features that your hypervisor uses.
Personally, i use snapshots of the qcow2 rather than snapshots of a btrfs filesystem with a raw image

Well yeah snapshots (either from qemu or btrfs) are great and all, but that wasn't really what I asked. I'm concerned about the whole self-healing data thing and not having to turn it off. See right now I have some stuff on ZFS and it's being kind of a pain in my ass because immutable vdevs and out-of-tree and all that, so I'd like to use Btrfs if I can. But I've also had ZFS save me from silent corruption several times with routine scrubs. That's what I want, and ideally I want it for everything, down to my boot drive, which presently doesn't have it, since a ZFS root filesystem on Linux is still kind of a pain. I could split the VM images off and put them somewhere else and son on, but it'd really simplify my setup if I could just have a Btrfs root with VM images on it, so that I'd get protection from corruption and shit for the OS, VM images, and whatever else in one go. That's what I'm after, much more than anything with snapshotting.

Is what you're saying that snapshotting VM images is the much bigger cause of fragmentation and misbehavior with VM images, moreso than just the routine random writes of a file where some VM has its root filesystem, so be judicious in the amount of that that you do?

I don't know how disabling COW will interfere with btrfs self healing, but it sounds like you know more than I do about this stuff so I'm not going to be able to help you at all.

>>I don't know how disabling COW will interfere with btrfs self healing,
Well the self-healing depends on checksums, and disabling CoW also disables those checksums.

>Basically, nodatacow bypasses the very mechanisms that are meant to provide consistency in the filesystem.
btrfs.wiki.kernel.org/index.php/FAQ#Can_I_have_nodatacow_.28or_chattr_.2BC.29_but_still_have_checksumming.3F

>but it sounds like you know more than I do about this stuff so I'm not going to be able to help you at all.
Oh well. thanks for trying though user

I guess my point would be that I don't really care self healing-- I honestly can't say I've run into those types of problems before. Having a snapshot and remote backups seems more robust since your drive can still fail other ways.

But if you don't want to disable COW then just use a raw image instead of COW-based (which provides snapshot functionality) disk image. I have used a COW image in btrfs before and it didn't "break"

read the entire thing, although im not a newbie,
i fail to understand what you are trying to do exactly, just move from zfs to btrfs?
how does VM comes into play with this, and what do you mean by blow up?

Well there's the CoW that Btrfs does at the filesystem level, that's totally different than the CoW that qemu is doing at the VM-image level. I'm only talking about the filesystem-level stuff. I'm not talking about whether or not to use .qcow2 or raw VM images, or anything involving what they virtualization software is doing.

I want to use Btrfs for my root filesystem and keep VM images on it, instead of having to keep those VM images elsewhere. I want to keep Btrfs's filesystem-level CoW turned on (regardless of whether I'm using hypervisor-level CoW VM images) for everything, because the filesystem-level CoW is needed for Btrfs's checksumming/self-healing stuff to work. That self-healing is the thing that I want for all my stuff, including the VM images.

Yes, as the above poster mentioned, make backups and all. Which I do. But filesystem checksumming has saved me before from silent corruption. That is, a drive coughed up bad data when a file was read and the filesystem noticed it and fixed it for me - when I might never have noticed it until it was too late. Hell, I might have made a backup between the time when the corruption happened and the time when I noticed it. Hopefully I'd notice it quickly, but who knows.

by "blow up" I mean that Btrfs has, in the past, had issues with files that get piles of random writes - database files and VM images are the prototypical examples.

The general impressions I get these days is that in the past (like, kernel 3.2) this could run you into nasty corner cases in the filesystem and lead to corruption, but that those bugs have since been squashed. But very poor performance may still be a risk due to massive fragmentation - because of the filesystem-level CoW that Btrfs does, it never just updates a file in place. Supposedly in recent (again, like, newer than 3.x recent) kernels autodefrag prevents this. What I want to know is how correct my impressions are.

>I'm not talking about whether or not to use .qcow2 or raw VM images, or anything involving what they virtualization software is doing.
right
so don't use a VM image with COW if you want to use COW in btrfs. i don't know why this problem is so complicated. you should check if your hypervisor disk image uses COW.

like I said. I accidentally had a qcow2 VM image on btrfs with COW enabled and didn't have any problems

To add on more than 2000 characters to that, I'm asking anons in this thread since I assume that /hsg/ folk might be more likely to play around with fancy filesystems and run VMs than the regular /fglt/ or /sqt/ crowd.

Btrfs had a really rocky start, as is well known, but that means when you google for stuff on it you get a lot of lore about things being horribly broken some years ago, and a lot of people these days saying essentially "Well, I haven't tried it, but I heard it has a lot of problems". It can be pretty hard to draw a bead on the state of it in this day and age, as opposed to back in 3.x. So I was hoping some anons would have some actual experience with it and be able to say either "Nah, that shit's still busted" or "I'm using 4.9 and things are fine"

>odroid
>vpn

what speeds do you get with that?

Storage spaces is shite, just get a dedicated san

Give ZFS a shot.

Terrible fragmentation issues but the ARC warms with use and negates the fact that you're so fragged. Long as you don't restart regularly, you're fine.

Oh and dropping the recordsize results in better random I/O with less time spent shooting write amplified contents to disk but you lose compress ratio and frag tighter, meaning longer ARC warmups.

Attached: 960-1200-max.jpg (960x1200, 154K)

it safe to say, dont use at production, or use at your own risks,
seeing that any major distro didnt adopt btrfs yet
i would trust them more,

you have your edge case, and i think finding the chance of some user to answer you are very slim

last time i check raid 5/6 is still broken, and the development is moving at snail pace.

lastly, im using btrfs on nas, i scrub data from time to time, its ok for general use, rocking debian 8

>last time i check raid 5/6 is still broken, and the development is moving at snail pace.
probably because the devs wouldn't use raid 6 so they won't bother making it functional. I'd rather see them work on built in encryption

>I sell the use of my Plex server for some normies friends, but the subscription fee+electricity cost of the server only left me 8-10 bucks a month of profit. It's nice tho.
you fucking kike

>cause of the ram and lan speed?
Yes to both
Installed everything manually, slowly adding services over the years.

~20 Mbps up/down