Ulrich Spoerlein wrote:
On Jan 18, 2008 9:11 AM, Johan Ström <[EMAIL PROTECTED]> wrote:
Your no,barely, bad hell no seems to fit pretty good.. I did some
testing during the night with the above (non-production) setup.
What I did was doing some rsyncing over the night:
while true ; do
echo "`date` Clearing vmail" >> logfile
rm -rf vmail
echo "`date` Starting rsync" >> logfile
rsync -vr /usr/var/vmail . |tee -a logfile
echo "`date` Rsync finished " >> logfile
done
I started this at ~02.0. The results? A freshly rebooted 6.2 (6.2-
RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Fri Jul 27 15:47:50 UTC 2007)
box in the morning..
[...]
What I dont have is a coredump, judging from dmesg -a savecore wasnt
even run.. running it now, 5 hours later, didnt find any cores.
The other end (7.0 server) wasnt affected at all.
Not realy sure what it had been doing, because looking at my
bandwidth graphs from the switch, nothing was done at all.. It didnt
even go through one iteration of rsync... ~7.5k files/directorys
seems to have been transfered, then the log doesnt say more. But
according to the BW graph, after ~03.00 no traffic was sent at all...
Some known bug with 6.2?
There was some ggatec problems with TCP and/or sockets, I think they
have been mostly resolved post-6.2. If you want to pursue this further
(it *would* be a cool setup, no doubt) I'd suggest three things:
- Update to 6.3
- Leave GELI out of the loop for now (only do ggate, with random data perhaps)
- Build a kernel *without* options PREEMPTION
Hi,
We have 4 production High Avaliability NFS clusters running
GMirror+GGate+LinuxHA (2 Nodes per cluster) on RELENG_6_2. This setup
has proved very stable for us you have to do some tuning though:
/etc/sysctl.conf:
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576
kern.ipc.maxsockbuf=2049152
/boot/loader.conf:
kern.ipc.nmbclusters="32768"
Command line options to ggate[cd]
ggate[dc]_buf_size="1310720"
ggatec_timeout="5"
ggatec_queue_size="2048"
Cluster node uptimes range from 40-160 days with the last reboots being
caused by power problems not FreeBSD issues.
The problems may be in the tuning or with geli, personally I would leave
geli out at try with the above configuration. Then try above with geli
to see what the problem is.
Tom
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
