Because new_pools was processed after old_pools, if something
was modified and then deleted in the same incremental
map, then the resulting state would be a pool in the map
that had no entry in pool_name.
Fixes: #12429
Signed-off-by: John Spray <john.spray@redhat.com>
librbd test cases attempt to enable lockdep coverage via the librados
API. Use a configuration observer to register/unregister lockdep
support.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Remove all depencencies on md_config_t and instead use librados API
methods to get/set configuration values.
Fixes: #12479
Backport: hammer
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Commit bd050240ce ("test_librbd_fsx: flush before discard in krbd
mode") added an fsync() before BLKDISCARD. Don't know what I was
thinking at the time, but I missed the invalidate part, for which we
need to use the BLKFLSBUF ioctl.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Otherwise, _flush() might continue to write to m_fd after it's closed.
This might cause log data to go to a data object if the filestore then
reuses the fd during that time.
Fixes: #12465
Backport: firefly, hammer
Signed-off-by: Samuel Just <sjust@redhat.com>
(cherry picked from commit 8778ab3a1c)
the first op id was 16 by default, which is okay, but a non-zero
magic number could lead to questions. max_op was mixed up with
max_ops, and changed to 16 in 51e402e3 by mistake.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The rbd CLI tool no longer attempts to initialize a CephContext
and pass said context to librados since it's possible that the
structure will not be ABI compatible between rbd and librados.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Switched to context-aware NSS init/shutdown functions to avoid conflicts
with parent application. Use a reference counter to properly shutdown the
NSS crypto library when the last CephContext is destroyed. This avoids
memory leaks with the NSS library from users of librados.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
...while injecting inodes. So that if you're a cephfs
admin but not uid=0 on the client, you can get things
injected as your choice of uid/gid.
Definitely useful for dev/test, potentially useful
elsewhere too.
Signed-off-by: John Spray <john.spray@redhat.com>
This is to deal with the slightly perverse situation
where a user might have all the permissions they need
to create a filesystem and mount it with fuse, but then
be unable to do anything inside the mount because
we default to creating a root-owned "/" inode.
This is immediatley useful for dev/test environments without
root, but also potentially in production environments
where the filesystem configuration/mounting is done by
someone less privileged than root.
Signed-off-by: John Spray <john.spray@redhat.com>
Still got xlist not empty asserts on deletion of MDSRank,
so reinstate the condition that we only delete on
is_stopped().
Additionally, allow deletion in the case that we never had
a rank to begin with.
Signed-off-by: John Spray <john.spray@redhat.com>
This case happens on rank acquisition because we
see the MDSMap before the OSDMap, as the continuous
watch on OSDMaps doesn't happen when we're in standby.
Signed-off-by: John Spray <john.spray@redhat.com>
It's now a bit confusing to have a class just called "MDS" --
rename it to MDSDaemon to make the distinction clear between
this and MDSRank.
It's easy because there are hardly any references to it now! This
patch also clears up a few stray references that were no longer
needed in OSDMap and Messenger.
Signed-off-by: John Spray <john.spray@redhat.com>
get_nodeid was used many places but not everywhere.
These can also be const now that MDSRank isn't constructed
until a rank is assigned.
Signed-off-by: John Spray <john.spray@redhat.com>
This is the separation between the parts of MDSRank
that are exposed downwards to subsystems, and
the parts that are exposed upwards to the daemon.
Signed-off-by: John Spray <john.spray@redhat.com>
Commented it out during refactor, now split
out the MDSRank-ish part. We can ditch
this at some point but there's no compelling
reason to do it now.
Signed-off-by: John Spray <john.spray@redhat.com>
Previously, if a buggy MDS sent a want_state=standby
beacon while it was in a rank-holding state, the MDSMonitor
would end up creating an inconsistent MDSMap.
Signed-off-by: John Spray <john.spray@redhat.com>
