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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If the same process tries to re-lock the same record
it has already locked, don't go to the ctdbd again.
There are situations where we already have a lock on a record
and then do a dbwrap_parse_record() on that record, for instance
in locking code:
do_lock()
-> grabs lock on brl record with brl_get_locks()
-> calls brl_lock()
-> calls brl_lock_posix or _windows_default()
-> calls contend_level2_oplocks_begin()
-> calls brl_locks_get_read_only()
-> calls dbwrap_parse_record on the same brl record as above
In the local (tdb) case, this is not a problem, because
identical fcntl locks in the same process don't contend each other,
but calling out to ctdb for this lets smbd and ctdb deadlock.
db_ctdb_fetch_lock() already correclty checks first
whether we can simply try to lock locally. But db_ctdb_parse_record()
failed to do so for empty records, i.e. records that only
consist of the ctdb record header. (These can be deleted records
but can also be freshly created and still empty records.)
This patch lets db_ctdb_parse_record() not skip local access
for empty records, hence fixing the deadlock.
PLAN: In the long run, it would be better to solve this
generically on the dbwrap_layer, i.e. root the notion of
an already locked record there, and skip any call to the
db (tdb or ctdb backend) if we have it. This would also
solve the problem for all calls like fetch_locked, parse_record
and possibly others. But this is the urgent fix for now.
Pair-Programmed-With: Volker Lendecke <vl@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Tested-by: Björn Baumbach <bb@sernet.de>
We have messaging_send_buf, so there's no point to use an explicit
DATA_BLOB here.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Christof Schmitt <cs@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Feb 25 23:27:21 CET 2014 on sn-devel-104
instead of the hand written test.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Feb 7 18:05:51 CET 2014 on sn-devel-104
To be consistent with db_open() and prepare for future
possible extensions.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
For non-persistent databases we try to use CTDB_CONTROL_SET_DB_READONLY
in order to make use of readonly records.
Pair-Programmed-With: Michael Adam <obnox@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
This is in preparation of directly supporting ctdb read only
record copies when opening a ctdb database from samba.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is in preparation to support handing flags to backends,
in particular activating read only record support for ctdb
databases. For a start, this does nothing but adding the
parameter, and all databases use DBWRAP_FLAG_NONE.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is made to replace the msg_channel abstraction.
msg_channel was created to not miss any messages. For this, some
complex queueing was installed. This complexity has caused quite a
few problems in the past (see bug 10284 for example).
messaging_read_send/recv is able to achieve the same goal with a
lot less complexity. The messaging_read_send atomically installs
the reader into the messaging_context, we will not miss any messages
while this installed. messaging_send_recv will deinstall that
listener, but in the callback function you can directly call
messaging_read_send again without going through the tevent_loop_once.
As long as this is always made sure, no messages will be lost.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This is consistent with the parameter using milliseconds and the other
warnings in the same file also using milliseconds.
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Thu Jan 16 11:19:39 CET 2014 on sn-devel-104
Avoid the parameter lookup for the warning thresholds in the hot code
path by reading them in db_open_ctdb and storing them in the
db_ctdb_ctx.
Signed-off-by: Christof Schmitt <cs@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
We need an indication whether we run into the fcntl thundering
herd. fcntl unlock should be blindingly fast in the normal case. If it
takes longer than 5 milliseconds, warn. The timeout can be adapted by
setting
ctdb:unlock_warn_threshold = <number-of-milliseconds>
Reviewed-by: Christof Schmitt <cs@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
With this patch, the number of fetch_lock attempts before dbwrap_ctdb
logs that it took x attempts to get a record is configurable with
net conf setparm global ctdb:migrate_attempts 10
This patch also adds
net conf setparm global ctdb:migrate_duration 5000
to trigger the same log message if it took longer than x milliseconds
to retrieve a record.
Reviewed-by: Christof Schmitt <cs@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
We have only a single allocation in this routine, so I think we can live
without a stackframe.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Christian Ambach <ambi@samba.org>
Autobuild-User(master): Christian Ambach <ambi@samba.org>
Autobuild-Date(master): Mon Mar 25 19:42:30 CET 2013 on sn-devel-104
db_tdb_fetch_locked returns the value as part of a larger talloc object
that also contains the key. This means we can not realloc, but have to
freshly alloc.
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Thu Nov 29 20:21:51 CET 2012 on sn-devel-104
Reviewed-by: Michael Adam <obnox@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Tue Nov 20 19:18:33 CET 2012 on sn-devel-104
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Fri Sep 21 18:05:56 CEST 2012 on sn-devel-104
