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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
there is still a bug in the ctdb code in that the children no longer receive messages from the parent for unknown reasons
(This used to be ctdb commit 468f68e4607900c5c38aea428a48dd6ea1647411)
this makes it possible to do fetch_lock and store_unlock across a domain socket to read/write data.
note that the actual locking is NOT implemented yet
(This used to be ctdb commit c7a397c56caf71283c081e5b97620085ed5108c6)
for now:
fetch a record
store a known entry for this record
fetch the record again (and later verify we got the same record)
store it back again
this will not work right now since we dont yet store the record inside the daemon
(This used to be ctdb commit f502094499a3c25ab58aa3d192588b5e6dd2b8e4)
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)
right now this test only does one fetch lock but this will be enhanced as more code is added to ctdb to handle fetch_lock and store_unlock
(This used to be ctdb commit 996f117d9181dee22aea979ce04333035f5522c7)
we cant peek in state->c since this is uninitialized
and even if it were not it would be wrong
create a new structure to pass BOTH client and also the reqid to respond back to
the client with
(This used to be ctdb commit e1a0da3dfbb4a927e8d98723b5e51a201c2a3428)
no locking is yet done and the store_unlock call is still missing
the ./tests/fetch.sh --daemon test fails with parent process dying which needs to be investigated.
(This used to be ctdb commit 7d7141c968950a8856f1be79871932b688bfb07f)
read returns 0 bytes this means the client has exited. Close the connection
then.
(This used to be ctdb commit bd10f4e62146493848258df8a3dc3b9222337a12)
(send a message to ourself)
this unfortunately terminates the ctdb daemon when running but im too tired right now to debug it.
checkin so that nothing gets lost overnight.
(This used to be ctdb commit 9d8821bfd1456591fb5c31f0c6c3fd63e99dc4fb)
create a small test application that connects to the ctdb daemon at /tmp/ctdb.socket.127.0.0.1 and do some commands to the daemon.
currently this test tool only opens the socket and registers its pid with the daemon
(the daemon needs to know the pid so that it can forward messages to the correct client)
the test will be extended with additional ctdb commands
(This used to be ctdb commit 801f6127cdd50c5b2d0e64dd8db08500af9dadc9)
