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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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
This matches the function's intention much closer, since it
also tests whether we have a valid local read only copy.
Pair-Programmed-With: Gregor Beck <gbeck@sernet.de>
The introduction of read only copies has broken the algorithm for
deteting whether we can use the local record copy for fetch_locked
and fetch: For fetch locked the new code always uses the local copy
if there is one...
This patch re-establish the original algorithm for the build against
a ctdb without read only record copies.
Reported-by: Gregor Beck <gbeck@sernet.de>
This helps clarify the role of this structure and wrapper function.
The purpose here is to provide helper functions to the lib/param
loadparm_context that point back at the s3 lp_ functions. This allows
a struct loadparm_context to be passed to any point in the code, and
always refer to the correct loadparm system. If this has not been
set, the variables loaded in the lib/param code will be returned.
As requested by Michael Adam.
Andrew Bartlett
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Jun 27 17:11:16 CEST 2012 on sn-devel-104
The flags returned were TDB-specific: this was only used for detecting
the endianness of obsolete databases (the conversion code was put in in
2003, with reference to Samba 2.3).
It's easier to remove it than to translate the NTDB flags to TDB flags,
and it's a really weird thing to ask for anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is designed to spread the load on individual ctdb records to allow upper
layers to do backoff mechanisms. In the ctdb case, do not get the record if a
local lock is already taken. If we are not dmaster, do at most one migrate
attempt.
For the tdb case, this is a nonblocking fetch_locked. If someone else has the
lock, give up.
It's a bit confusing to mix low-level and high-level libraries. We had
multiple libraries in one directory, and there were have circular
dependencies with other libraries outside that directory (in this case,
samba-hostconfig).
Autobuild-User: Jelmer Vernooij <jelmer@samba.org>
Autobuild-Date: Sat Mar 10 23:13:01 CET 2012 on sn-devel-104
Because revoking read-only copies of records is expensive, we only
want ctdbd to do it for high-turnover records. A basic heuristic is
that if we don't find a local copy of the record, don't ask for a
read-only copy.
The fetch itself will cause ctdbd to migrate the record, so eventually
we will have a local copy. Next time it gets migrated away, we'll
call ctdbd_fetch() with local_copy = true.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The new read-only record flags make determining if we can use a record
a bit more complex, so extract it into its own function.
The OLD logic was:
1) If the record doesn't exist, we can't use it.
2) If we are the dmaster for the record, we can use it.
The new logic is:
1) If the record doesn't exist, we can't use it.
2) If we are the dmaster for the record, we can use it IF we only
want read-only access, OR there are no read-only delegations.
3) If we are not dmaster, we can only use it if we want read-only
access and it is marked as a read-only copy.
This logic is unused until the next patches which begin to ask
for read-only copies of records.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
