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 database isn't use throughout CTDB, so name the it more
specifically.
Note that this might cause locks to be lost during upgrade to the
first version containing this change.
For testing, a different name is chosen to exercise related
functionality.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Fri Dec 13 15:01:10 UTC 2024 on atb-devel-224
CTDB_STATD_CALLOUT_SHARED_STORAGE is a new configuration variable
indicating where statd-callout should store its NFS client locking
data. See the update to ctdb-script.options(5) for details.
This adds back functionality that was removed in commit
12cc82623150ca4a83482f1b7165401cbdecd3de. The commit message doesn't
say why this was changed but it was most likely due to a cluster
filesystem hanging at inopportune times. Hence, this is re-added as a
non-default option. There are 2 justifications for re-adding it:
* The existing method (persistent_db) relies on dequeuing data during
the monitor event, which loses any queued data on node crash.
* NFS-Ganesha writes NFSv4 client locking data to a cluster
filesystem, by default. Something similar might as well exist for
NFSv3.
Note that this could create the files for sm-notify in add-client.
However, this would require an alternate implementation of
send_notifies() (or a change to the implementation for persistent_db
too). It seems better to leave add-client lightweight and do the work
in notify, since add-client is a more frequent operation.
Unconditionally create the state directory on startup. This is
currently implicitly created for persistent_db when the queue
directory is created. However, it isn't created anywhere else for
shared_dir, so do it in a common place.
In test mode, the shared storage location has a prefix added so files
are created within the test environment.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
SM_NOTIFYs are sent before client records are deleted. Theoretically,
this means new records resulting from lock reclaim can be deleted.
This doesn't actually happen at the moment because any new "records"
resulting from lock reclaim are entered into the queue directory and
only dequeued to the database during a later monitor event. Since a
monitor event can't collide with an ipreallocated event, no records
can be dequeeued into the database during the ipreallocated event, so
they can't be deleted by delete_records().
However, a subsequent commit will add direct writing of records into a
shared cluster filesystem directory. This means that add-client
events will cause records to be added directly to that directory so,
without a fix, the race will be able to occur.
So, delete records before sending SM_NOTIFYs. In theory, the script
could be killed before all SM_NOTIFYs are successfully sent, resulting
in loss of locks. However, given the overall lack of error checking,
there are other, more likely problems.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This captures all of the persistent database (currently ctdb.tdb)
implementation-specific details in functions. Alternate
implementations can now be easily added.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Drop the complexity associated with using awk to escape dots in IPv4
addresses to protect them from sed, and generate a grep -F filter
instead.
For listing, the pipeline is now longer, but the steps are now
clearer:
1. List DB records
2. Extract keys
3. Keep only keys machine hosted public IPs
4. Parse out server IP and client IP
5. Sort
Performance here isn't critical, so having clearer code is preferable.
Use temporary files to avoid command-line length limits.
Also, drop the cd to the queue directory during update.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Commits caad5dc38d790d76f6720b312c1557ec3151a084 and
f022df1d40c9c1e3e528f178204f404ee395d5c2 commented out these lines
back in 2007.
2 things are clear from the commit messages:
* These setting should not be required in the real world - they are:
mainly useful for avoiding ack-storms when doing very rapid
failover/failback during testing
* If they are needed, they are not specific to
statd_callout/statd_callout_helper
Let's remove these comments to avoid confusing people.
Reported-by: Ulrich Sibiller <ulrich.sibiller@eviden.com>
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The top comment in the file is no longer true.
The comment about notifications doesn't really apply anymore since
upstream sm-notify is used and it does "the right thing".
shfmt wants to remove a space before a semicolon, so do that too.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This was passed to CTDB's old smnotify. This has been replaced by use
of nfs-utils' sm-notify, which doesn't need this.
In test, a fake NFS_HOSTNAME is still needed. Real sm-notify will get
it from a reverse host lookup of the IP address.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
CTDB's smnotify does not support IPv6 and is difficult to maintain.
So, create directories of files and pass them to NFS util's sm-notify.
There is an implied change here, because NFS utils sm-notify stopped
sending IP addresses as mon_name back in 2010:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=900df0e7c0b9006d72d8459b30dc2cd69ce495a5
This will change advice given in the wiki to use a hostname for the
cluster with round-robin DNS, since this is what is best supported.
Another behavioural change is that sm-notify only sends "up"
notifications with an odd state.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
rpc.statd is single-threaded and runs its HA callout synchronously. If
it is too slow then latency accumulates and rpc.statd's backlog grows.
Running a pair of add-client/del-client events with the current code
averages ~0.030s in my test environment. This mean that 1000 clients
reclaiming locks after failover can easily cause 10s of latency. This
could cause rpc.statd to become unresponsive, resulting in a time out
for an rpcinfo-based health check of the status service.
Split the add-client/del-client events out to a standalone
statd_callout executable, written in C, to be used as the HA callout
for rpc.statd. All other functions move to statd_callout_helper.
Now, running a pair of add-client/del-client events in my test
environment averages only ~0.002s. This seems less likely to cause
latency problems.
The standalone statd_callout executable needs to read a configuration
file, which is generated by statd_callout_helper from the "startup"
event. It also needs access to a list of currently assigned public
IPs.
For backward compatibility, during installation a symlink is created
from $CTDB_BASE/statd-callout to the new statd_callout, which is
installed in the helper directory.
Testing this as part of the eventscript unit tests starts to become
even more of a hack than it used to be. However, the dependency on
stubs and the corresponding setup of fake state makes it hard to move
this elsewhere.
Signed-off-by: Martin Schwenke <mschwenke@ddn.com>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
