IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
keepalive traffic for x seconds it is deemed dead
this triggers a recovery after a while if a ctdbd has been STOPPED
but it doesnt recover automatically when the node reappears
(This used to be ctdb commit d6324afe0d13b5e21d06e347caca433c6b36a32a)
- increment rsn only in become_dmaster
- add torture check for rsn regression in ctdb_ltdb_store
(This used to be ctdb commit 8047506a08bb53ee01aa64f25c9f72839e1e2d68)
to make sure that the "merge records based on rsn during recovery" will
merge correctly.
this is extra important since samba3 never bumps the record when it
writes new data to it !
(This used to be ctdb commit 857e67204065603592c2dbbadbd8667ebba9ccdb)
- fixed the re-send of ctdb calls after a generation change
- fixed a reqid idr leak in controls
- removed the write_record test code
- use the new nonblock lockall code to prevent ctdbd from ever doing a
blocking lock that could deadlock with smbd
- moved more of the recovery controls into ctdb_recover.c
(This used to be ctdb commit 565a21aa4f1e842309986ab97d6244801153deec)
for 2 days.
The main bug was in smbd, but there was a secondary (and more subtle)
bug in ctdb that the bug in smbd exposed. When we get send a dmaster
reply, we have to correctly update the dmaster in the recipient even
if the original requst has timed out, otherwise ctdbd can get into a
loop fighting over who will handle a key.
This patch also cleans up the packet allocation, and makes ctdbd
become a real daemon.
(This used to be ctdb commit 59405e59ef522b97d8e20e4b14310a217141ac7c)
this will allow a node to verify that a received pdu is sent from a node
in the same generation instance of a cluster.
(This used to be ctdb commit e32d3ca9a622237c4e2622de98825c0962760d48)
store the idr as the high 16 bits and use a rotating counter for the low
16 bits.
(This used to be ctdb commit 7c763b7b5e6ca54a6df4586893ddaf1b508b4c22)
lmaster instead of what the nodes think is the dmaster (which might be
stale) improve performance.
(This used to be ctdb commit f535f79e6a2a6c6d07141b96e0b957fa93c684f4)
dmaster request stage, and instead directly send a dmaster
reply. This avoids a race condition where a new call comes in for
the same record while processing the dmaster request
- don't keep any redirect records during a ctdb call. This prevents a
memory leak in case of a redirect storm
(This used to be ctdb commit 59889ca0fd606c7d2156839383a09dfc5a2e4853)
processed immediately, but the input routines indirectly assumed
they were being called as a new event (for example, a calling
routine might queue the packet, then afterwards modify the ltdb
record). The solution was to make self packets queue via a zero
timeout.
- fixed unlinking of the socket in a exit in the lockwait code. Needed
an _exit instead of exit so atexit() doesn't trigger
- print latency of lockwait delays
(This used to be ctdb commit 1b0684b4f6a976f4c5fe54394ac54d121810b298)
ctdb_ltdb_lock_requeue() and a small wrapper
- use ctdb_ltdb_lock_requeue() to fix a possible hang in
ctdb_reply_dmaster(), where the ctdb_ltdb_store() could hang waiting
for a client. We now requeue the reply_dmaster packet until we have
the lock
(This used to be ctdb commit 97cd7aa09ce3abbb5e3e965c5c81668e0c0133a5)
CTDB_FLAG_TORTURE, which forces some race conditions to be much more
likely. For example a 20% chance of not getting the lock on the
first try in the daemon
- abstraced the ctdb_ltdb_lock_fetch_requeue() code to allow it to
work with both inter-node packets and client->daemon packets
- fixed a bug left over in ctdb_call from when the client updated the
header on a call reply
- removed CTDB_FLAG_CONNECT_WAIT flag (not needed any more)
(This used to be ctdb commit 7559dcd184666c3853127e3c8f5baef4fea327c4)
version. The client version is different enough that this is
worthwhile
- enable local shortcut for client version of ctdb_call
- add idr_find_type(), with better error reporting in case of type
mismatch
(This used to be ctdb commit 2388094c5f7b6ce003e86b05620c06217d63b49c)
us to put memory directly in the right context, avoiding quite a few
talloc_steal calls, and simplifying the code
- make the fetch lock code in the daemon fully async
(This used to be ctdb commit d98b4b4fcadad614861c0d44a3854d97b01d0f74)
a client held the chainlock, and the daemon received a dmaster reply
at the same time. The daemon would not be able to process the dmaster
reply, due to the lock, but the fetch lock cannot make progres until
the dmaster reply is processed.
The solution is to not hold the lock in the client while talking to
the daemon. The client has to retry the lock after the record has
migrated. This means that forward progress is not guaranteed. We'll
have to see if that matters in practice.
(This used to be ctdb commit 737e5a1253cb048222c595a474aff71c99fc554f)
- fixed memory leaks in the 3 packet receive routines. The problem was
that the ctdb_call logic would occasionally complete and free a
incoming packet, which would then be freed again in the packet
receive routine. The solution is to make the packet a child of a
temporary context in the receive routine then free that temporary
context. That allows other routines to keep or free the packet if
they want to, while allowing us to safely free it (via a free of the
temporary context) in the receive function
(This used to be ctdb commit 304aaaa7235febbe97ff9ecb43875b7265ac48cd)
fetch, to avoid the daemon re-reading it
- suffix the database name with the node name so that testing on
loopback doesn't result in a name collision in the database open
(This used to be ctdb commit ad30a4db75450643ff146c40faa306a021de3dd2)
code. It may be added back later once everything is working nicely,
or simulated using a in-process pipe instead of a unix domain socket
- rewrote the ctdb_fetch_lock() code to follow the new design
(This used to be ctdb commit 5024dd1f305fe1ecc262db2240c56f773b4f28f0)
- when we do a store_unlock the lock record becomes unlocked, so we
must destroy it (or we leak memory)
(This used to be ctdb commit d85955640e670dd580073da96b25fb8a10c08d18)
note that the store_unlock does not actually do anything yet apart from passing the pdu from client to daemon and daemon responds.
next is to make sure the daemon actually stores the data in a database
(This used to be ctdb commit 167d6993e78f6a1d0f6607ef66925a14993ae6a1)
