Date: Sun, 10 Apr 2011 15:48:16 +0000 (UTC) From: Mikolaj Golub <trociny@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sbin/hastd hast.conf.5 hast.h primary.c proto_common.c secondary.c Message-ID: <201104101548.p3AFmQgD091743@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
trociny 2011-04-10 15:48:16 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_8)
sbin/hastd hast.conf.5 hast.h primary.c
proto_common.c secondary.c
Log:
SVN rev 220525 on 2011-04-10 15:48:16Z by trociny
MFC r220005, r220006, r220007, r220266, r220270, r220271, r220272,
r220273, r220274:
r220005 (pjd):
Use role2str() when setting process title.
r220006 (pjd):
Use timeout from configuration file not only when sending and receiving,
but also when establishing connection.
r220007 (pjd):
Add mapsize to the header just before sending the packet.
Before it could change later and we were sending invalid mapsize.
Some time ago I added optimization where when nodes are connected for the
first time and there were no writes to them yet, there is no initial full
synchronization. This bug prevented it from working.
r220266 (pjd):
Handle the problem described in r220264 by using GEOM GATE queue of unlimited
length. This should fix deadlocks reported by HAST users.
r220270 (pjd):
Allow to disable sends or receives on a socket using shutdown(2) by
interpreting NULL 'data' argument passed to proto_common_send() or
proto_common_recv() as a will to do so.
r220271 (pjd):
Declare directions for sockets between primary and secondary.
In HAST we use two sockets - one for only sending the data and one for only
receiving the data.
r220272 (pjd):
When we are operating on blocking socket and get EAGAIN on send(2) or recv(2)
this means that request timed out. Translate the meaningless EAGAIN to
ETIMEDOUT to give administrator a hint that he might need to increase timeout
in configuration file.
r220273 (pjd):
Handle ENOBUFS on send(2) by retrying for a while and logging the problem.
r220274 (pjd):
Increase default timeout from 5 seconds to 20 seconds. 5 seconds is definitely
to short under heavy load and I was experiencing those timeouts in my recent
tests.
Approved by: pjd (mentor)
Revision Changes Path
1.1.2.6 +2 -2 src/sbin/hastd/hast.conf.5
1.1.2.7 +1 -1 src/sbin/hastd/hast.h
1.3.2.13 +8 -3 src/sbin/hastd/primary.c
1.1.2.7 +79 -4 src/sbin/hastd/proto_common.c
1.1.2.9 +9 -2 src/sbin/hastd/secondary.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104101548.p3AFmQgD091743>