I'm currently considering a switch from ext4 to ZFS and am having trouble finding information about whether or not it uses more or less space to store the same amount of data as ext4. My understanding is that it uses checksums for data integrity, which I'm assuming comes at a cost of more physical space used when compared to ext4. Since it seems nobody is talking about this, I wonder if perhaps the compression (which I understand is enabled by default) more than makes up for the space used by the checksums?
We have a couple dozen Proxmox servers (Proxmox runs on Debian), and about once a month, one of them will have a kernel panic and lock up. The worst part about these lock ups is that when it's a server that is on a separate switch than the cluster master, all other Proxmox servers on that switch will stop responding until we can find the server that has actually crashed and reboot it.
When we reported this issue on the Proxmox forum, we were advised to upgrade to Proxmox 3.1 and we've been in the process of doing that for the past several months. Unfortunately, one of the servers that we migrated to Proxmox 3.1 locked up with a kernel panic on Friday, and again all Proxmox servers that were on that same switch were unreachable over the network until we could locate the crashed server and reboot it.
Well, almost all Proxmox servers on the switch... I found it interesting that the Proxmox servers on that same switch that were still on Proxmox version 1.9 were unaffected.
Here is a screen shot of the console of the crashed server:
When the server locked up, the rest of the servers on the same switch that were also running Proxmox 3.1 became unreachable and were spewing the following:
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...
uname -a output of locked server:
Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux
pveversion -v output (abbreviated):
proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109
Two questions:
Any clues what would be causing the kernel panic (see image above)?
Why would other servers on the same switch and version of Proxmox be knocked off the network until the locked server is rebooted? (Note: There were other servers on the same switch that were running the older 1.9 version of Proxmox that were unaffected. Also, no other Proxmox servers in the same 3.1 cluster were affected that were not on that same switch.)
Thanks in advance for any advice.
I've got a rack full of Linux servers that host OpenVZ containers and for some reason when I attempt to connect to a certain remote IP from inside a few of the OpenVZ containers (using telnet, for example), I end up connecting to another server on the local network instead. So far, I have looked at the following possibilities:
Checked the server that I'm trying to make the outbound connection from to make sure there are no iptables rules that would redirect the remote IP to a local ip.
Checked our router/firewall to make sure there are no rules that would redirect this outbound connection to a local ip.
Checked the OpenVZ container that it is erroneously connecting to and made sure that it does not have the remote IP configured as an IP alias.
All OpenVZ containers are running CentOS 5.x.
I'm sure it's something simple, but I'm running out of ideas.
Just wondering if anyone sees any clues from the following screen shot as to what might have caused this server to lock up:
This server also locked up 6 months ago, and I still have the screen shot from that too:
The server is running Proxmox 1.8 (which is based on Debian Lenny, but a kernel that I think comes from OpenVZ). uname output (host name masked):
Linux ------ 2.6.32-4-pve #1 SMP Mon May 9 12:59:57 CEST 2011 x86_64 GNU/Linux
Does anyone see any clues based on these screen shots as to whether this is a hardware or software issue?
A couple of our servers have ST32000641AS (2TB Seagate desktop drives) in RAID 10 using an Adaptec 2405 controller. I've been told by Adaptec that this is a bad idea and we have, in fact, already seen one raid system go down using these drives. Since this is a 24/7 system, my question is whether it would be possible to switch over to WD RE4 2TB raid edition drives (model WD2003FYYS) by hot swapping them, one by one until we've migrated over. We would wait between each drive to make sure the raid has rebuilt itself.
In theory, this should work... however, one thing I can't figure out is whether these drives are the exact same size or not. Unfortunately, the raid build on the ST32000641AS drives are partitioned to capacity. If the WD2003FYYS drives are even the slightest bit smaller, it's not going to work. Any ideas on where I can go to learn whether the WD2003FYYS drive is exactly as big (or bigger) than then ST32000641AS?
Yes, I realize that both drives advertise themselves as 2TB drives...
I had a server lock up this morning. Here is a screen shot from the console:
None of the messages from the screen shot mean anything to me. I have a feeling that the important stuff probably scrolled off the console. I can not find any of the messages from the above screen capture in the syslog, message, dmesg, debug logs or anything logged at all at the time of the crash. Shouldn't this stuff have been logged?
This is a Debian box running Proxmox. uname output:
2.6.32-4-pve #1 SMP Mon May 9 12:59:57 CEST 2011 x86_64 GNU/Linux
The server has been online for about a year with no other crashes and it booted up again just fine.
I would love to figure out what the issue might have been so that we can prevent it from occurring again in the future. But, from the evidence I have so far, I don't even know if this was a hardware or software issue. Ideas?
I have a fairly simple iptables firewall on a server that provides MySQL services, but iptables seems to be giving me very inconsistent results.
The default policy on the script is as follows:
iptables -P INPUT DROP
I can then make MySQL public with the following rule:
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
With this rule in place, I can connect to MySQL from any source IP to any destination IP on the server without a problem. However, when I try to restrict access to just three IPs by replacing the above line with the following, I run into trouble (xxx=masked octect):
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.184 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.196 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.251 -j ACCEPT
Once the above rules are in place, the following happens:
I can connect to the MySQL server from the .184, .196 and .251 hosts just fine as long as am connecting to the MySQL server using it's default IP address or an IP alias in the same subnet as the default IP address.
I am unable to connect to MySQL using IP aliases that are assigned to the server from a different subnet than the server's default IP when I'm coming from the .184 or .196 hosts, but .251 works just fine. From the .184 or .196 hosts, a telnet attempt just hangs...
# telnet 209.xxx.xxx.22 3306 Trying 209.xxx.xxx.22...If I remove the .251 line (making .196 the last rule added), the .196 host still can not connect to MySQL using IP aliases (so it's not the order of the rules that is causing the inconsistent behavior). I know, this particular test was silly as it shouldn't matter what order these three rules are added in, but I figured someone might ask.
If I switch back to the "public" rule, all hosts can connect to the MySQL server using either the default or aliased IPs (in either subnet):
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
The server is running in a CentOS 5.4 OpenVZ/Proxmox container (2.6.32-4-pve).
And, just in case you prefer to see the problem rules in the context of the iptables script, here it is (xxx=masked octect):
# Flush old rules, old custom tables
/sbin/iptables --flush
/sbin/iptables --delete-chain
# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
# Enable free use of loopback interfaces
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Accept inbound TCP packets (Do this *before* adding the 'blocked' chain)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow the server's own IP to connect to itself
/sbin/iptables -A INPUT -i eth0 -s 208.xxx.xxx.178 -j ACCEPT
# Add the 'blocked' chain *after* we've accepted established/related connections
# so we remain efficient and only evaluate new/inbound connections
/sbin/iptables -N BLOCKED
/sbin/iptables -A INPUT -j BLOCKED
# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT
# ssh (private)
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT
# ftp (private)
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT
# www (public)
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# smtp (public)
/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 2525 -j ACCEPT
# pop (public)
/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
# mysql (private)
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.184 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.196 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.251 -j ACCEPT
Any ideas? Thanks in advance. :-)