Simple question: is it stupid to run mongodb and elasticsearch on the same nodes within a cluster of three if you take care of mongodb's memory hunger using cgroups and ignore the aspect of concurring io?
I have setup a linux box (on an esxi5) which acts as an OpenVPN server. the server is configured to use bridging for the clients, which essentially works, with one exception.
If the client pings some machine on the network which is not the server itself it does not work. I ruled out everything I know of (iptables, etc) and running tcpdump boiled it down to the following things:
- I see ARP requests on tap0 and br0
- I see the ARP replies on br0
- I do NOT see the ARP replies on tap0
Question: why does the br0 device not forward ARP replies to the tap0 device?
After deciding to use LVM2 as volumemanager on our servers there was also the wish for an online resizeable filesystem. After reading a few articles I decided to use JFS in favour of XFS.
Now today I had a power outage on our office server and I discovered that one file on the JFS volume has been completely corrupted. While this might happen the system fooled me into believing everything is alright by not indicating any filesystem problems during the bootup after the power failure. All filesystems were clean after replaying the journal.
This leaves me with a bad taste. I don't want a filesystem which would not recover well after a power outage, but I really don't want a filesystem which doesn't tell me that there might be a problem.
So I thought I give it a shot and ask which filesystem do you prefer? Which one do you favour and why? I'm looking for the following features:
- robust
- online growable
- good performance for usual workloads (normal filesizes - nothing special like millions of small files or such)
- available in the CentOS 5.4 distribution, but that's optional
I'd also like to know if you have used JFS and have had bad experiences with it - also of course if there're success stories using JFS. And ultimately: would you prefer XFS over JFS or vice versa (as mentioned for everyday use, not for specific workloads)