Xiubo Li [Mon, 4 Mar 2024 03:38:28 +0000 (11:38 +0800)]
mds/client: return -ENODATA when xattr doesn't exist for removexattr
The POSIX says we should return -ENODATA when the corresponding
attribute doesn't exist when removing it. While there is one
exception for the acl ones in the local filesystems, for exmaple
for xfs, which will treat it as success.
While in the MDS side there have two ways to remove the xattr:
sending a CEPH_MDS_OP_SETXATTR request by setting the 'flags' with
CEPH_XATTR_REMOVE and just issued a CEPH_MDS_OP_RMXATTR request
directly.
For the first one it will always return 0 when the corresponding
xattr doesn't exist, while for the later one it will return
-ENODATA instead, this should be fixed in MDS to make them to be
consistent.
Added a CEPH_XATTR_REMOVE2 new flags and will return -ENODATA errno
directly when the crresponding xattr doesn't exist. Just keeps the
old CEPH_XATTR_REMOVE flags to make it to be compatible with old
clients.
Fixes: https://tracker.ceph.com/issues/64679 Signed-off-by: Xiubo Li <xiubli@redhat.com>
Venky Shankar [Thu, 27 Jun 2024 16:34:37 +0000 (22:04 +0530)]
Merge PR #57619 into main
* refs/pull/57619/head:
qa/cephfs: use wait_for_daemon() instead of sleep()-ing
qa/cephfs: mark file system joinable for fs rename tests before unmounting clients
Venky Shankar [Thu, 27 Jun 2024 14:28:50 +0000 (19:58 +0530)]
Merge PR #53755 into main
* refs/pull/53755/head:
PendingReleaseNotes: add note about CephFS set_vxattrs
doc/cephfs: Update docs to match remove functionality and respective vxattrs
qa: Add test coverage for vxattr behavior
qa: Add removexattr to support setfattr removal.
mds: Implement remove for ceph vxattrs
After rollback started being tested in commit b3977c53c930
("test/librbd: make rollback in TestGroup.add_snapshot{,PP}
meaningful"), these tests can fail on comparing post-rollback
data to expected data if run with exclusive lock disabled.
This doesn't occur with exclusive lock enabled because the RBD
cache gets invalidated implicitly before releasing the lock.
While at it, pass LIBRADOS_OP_FLAG_FADVISE_FUA to avoid relying
on any cache settings that happen to be in effect.
Pere Diaz Bou [Wed, 26 Jun 2024 13:57:47 +0000 (15:57 +0200)]
doc/rados: update how to install c++ header files
In this example librados2-devel only install C header files on fedora 40,
therefore I added libradospp-devel to the command to include C++ header files.
Signed-off-by: Pere Diaz Bou <pere-altea@hotmail.com>
Nizamudeen A [Wed, 26 Jun 2024 13:22:40 +0000 (18:52 +0530)]
mgr/dashboard: fix clone async validators with different groups
Providing a way to dynamically update the async validator based on the
selector field so that when the selected value changes, the depended
field like the clone name gets validated again against the new value
Fixes: https://tracker.ceph.com/issues/66703 Signed-off-by: Nizamudeen A <nia@redhat.com>
Xuehan Xu [Fri, 14 Jun 2024 10:35:05 +0000 (18:35 +0800)]
crimson/os/seastore/cache: add an efficient method to check if extents are
viewable to transactions
Instead of searching the transaction's retired_set to determine whether
an extent has been retired, we add the transaction that's retiring an
extent to that extent's retired_transactions field and search that field
to do the check. Since the probability of multiple transactions retiring
the same extent is very low, this approach should be more cpu efficient.
Casey Bodley [Mon, 24 Jun 2024 15:23:36 +0000 (11:23 -0400)]
dout: add macros for libfmt-style logging
new dout macros use fmt::print() to write output directly to the
underlying ostream. this enables libfmt's printf-style formatting syntax
for ceph log output, without the string allocation overhead of:
Patrick Donnelly [Tue, 25 Jun 2024 16:27:28 +0000 (12:27 -0400)]
Merge PR #53503 into main
* refs/pull/53503/head:
qa: add tests for `mds last-seen` command
doc/cephfs: add documentation for `mds last-seen`
PendingReleaseNotes: add note on last-seen command
mon/MDSMonitor: add command to lookup when mds was last seen
mon/MDSMonitor: set birth time on FSMap during encode
pybind/mgr/dashboard: show context diff for openapi check
Ilya Dryomov [Mon, 24 Jun 2024 13:25:11 +0000 (15:25 +0200)]
pybind/rbd: change to return "aware" datetime objects
utcfromtimestamp() and utcnow() have been deprecated in Python 3.12.
Let's follow suit because it turns out that many datetime methods in
Python 3 interpret "naive" objects that we are currently returning as
local times.
Connor Fawcett [Fri, 21 Jun 2024 15:31:33 +0000 (16:31 +0100)]
nasm-wrapper: Exclude --coverage flag from being passed to nasm
A previous fix for compiling with gcov code coverage enabled forgot to
stop the --coverage flag being passed to nasm during compile,
this breaks compilation as nasm doesn't recognise this flag.
Venky Shankar [Tue, 25 Jun 2024 07:09:33 +0000 (12:39 +0530)]
Merge PR #56429 into main
* refs/pull/56429/head:
mds: fix rank root doesn't insert root ino into its subtree map when starting
mds: flush mds log before finishing STATE_STARTING
mds/FSMap: go back to STARTING state when rank doesn't make it pass STARTING
Reviewed-by: Venky Shankar <vshankar@redhat.com> Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Zac Dover [Mon, 24 Jun 2024 10:32:30 +0000 (20:32 +1000)]
doc/rados: edit troubleshooting-osd.rst
Make minor changes to the "Debugging Slow Requests" section of
doc/rados/troubleshooting/troubleshooting-osd.rst in preparation
for an expansion of this section in response to a reqeust from Joel
Davidow.
Samuel Just [Wed, 19 Jun 2024 04:10:34 +0000 (21:10 -0700)]
crimson/.../object_context: drop recovery_read_marker
This doesn't seem to serve a purpose with current crimson. classic
uses ObjectState::recovery_read_marker to indicate that backfill
should be requeued upon wakeup, but that hasn't been necessary so
far in crimson. We can reintroduce this if it becomes useful.
Samuel Just [Thu, 13 Jun 2024 00:47:08 +0000 (00:47 +0000)]
crimson/.../tri_mutex: lock() methods return normal future
f63d76a2 modified the lock() variants on tri_mutex so that the obc
loading pathway wouldn't invoke .then() on returned future known
statically to be ready. Now that the loading pathway uses demotion
mechanisms that cannot block and do not return futures, we no longer
have any users like that and can drop the extra std::nullopt
possibility.
In a larger sense, if lock() *can* return a non-ready future in a
particular pathway, there's no semantic difference between returning
std::optional<future<>> and future<> as the caller would still have to
deal with a possible non-ready future return even if std::nullopt is
also possible. If the pathway can be demonstrated statically to be
non-blocking, as with the obc loading mechanism, we really want to use a
mechanism that obviously cannot block rather relying on a mechanism with
a return signature of std::optional<future<>> to return std::nullopt.
Patrick Donnelly [Sun, 23 Jun 2024 18:29:53 +0000 (14:29 -0400)]
Merge PR #57754 into main
* refs/pull/57754/head:
mds: set the proper extra bl for the create request
mds: encode the correct extra info depending on the feature bits
mds: add set_reply_extra_bl() helper support
mds: cleanup the code to make it to be more readable
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com> Reviewed-by: Greg Farnum <gfarnum@redhat.com>
Ilya Dryomov [Thu, 20 Jun 2024 19:13:56 +0000 (21:13 +0200)]
librbd: make diff-iterate in fast-diff mode aware of encryption
diff-iterate wasn't updated when librbd was being prepared to support
encryption in commit 8d6a47933269 ("librbd: add crypto image dispatch
layer"). This is even noted in [1]:
> The two places I skipped for now are DiffIterate and TrimRequest.
CryptoImageDispatch has since been removed, but diff-iterate in
fast-diff mode is still unaware of encryption and just assumes that all
offsets are raw. This means that the callback gets invoked with
incorrect image offsets when encryption is loaded. For example, for
a LUKS1-formatted image with some data at offsets 0 and 20971520,
diff-iterate with encryption loaded reports
as "exists". For any piece of code that is using diff-iterate to
optimize block-by-block processing (e.g. copy an encrypted source image
to a differently-encrypted destination image), this is fatal: it would
skip processing block 20971520 which has data and instead process block 25165824 which doesn't have any data and was to be skipped, producing
a corrupted destination image.
Currently we are laying data only at the beginning of an object.
Extend the skeletons to write to three different offsets in the middle
and also at the end of the object.
Separately, make C and C++ API test variants slightly different in
terms of offsets being targeted to not go through exactly the same
scenario twice.
projects / ceph.git / log