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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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)
change ctdb_client_fetch_lock to return a status code instead of a record handle and make it unconditionally fill in data.
change ctdb_client_store_unlock to take ctdb_db and key as arguments instead of a record handle
update the ctdb_fetch.c test to use the clientside helpers for fetching and storing data
(This used to be ctdb commit 22d5d40375e0135916c97945646f94119612615d)
this will be the core of the non-blocking lock idea for ctdb, it will be used
in place of ctdb_ltdb_fetch(), but will also get a lock. It re-starts a request
if it needs to block
(This used to be ctdb commit afa479026cf6293e6a878c8a329cdac035284672)
The problem we have is this:
- we want the client smbd processes to be able to 'shortcut' access
to the ltdb, by directly accessing the ltdb, and if the header of
the record shows we are the dmaster then process immediately, with
no overhead of talking across the unix domain socket
- a client doing a shortcut will use tdb_chainlock() to lock the
record while processing
- we want the main ctdb daemon to be able to set locks on the
record, and when those locks collide with a 'shortcut' fcntl lock,
we want the ctdb daemon to keep processing other operations
- we don't want to have to send a message from a smbd client to the
ctdbd each time it releases a lock
The solution is shown in this example. Note that the expensive fork()
and blocking lock is only paid in case of contention, so in the median
case I think this is zero cost.
(This used to be ctdb commit a3248c3e2b740cd2403acffd3c1f6a33dca0ea03)
- 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)
they both successfully fetch and lock the same record at this stage but when the actual locking works properly the second child will block.
this test allows us to verify the blocking once we have implemented it
(This used to be ctdb commit b1c0baa03a669757aaacb6e1a2794224f5ba2cd7)
