When encryption is loaded, rbd_get_overlap() and Image::overlap() now
return "effective" overlap, similar to rbd_get_size() and Image::size().
Previously, returned overlap could have been bigger than "effective"
size.
Note that get_effective_image_size() successor doesn't take snap_id
because passing anything but ictx->snap_id was broken. Since the size
of the crypto header is stored in the crypto header itself, image areas
are defined only for the "opened at" snap_id. Getting "effective" size
for an arbitrary snapshot requires actually opening it and loading
encryption on it.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Make it clear that get_parent_overlap() returns the raw parent overlap
value (i.e. physical offset into the parent image). Also drop redundant
ceph_mutex_is_locked assert -- get_parent_info() already has one.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
When encryption is loaded, rbd_get_size() and Image::size() return
"effective" size, but rbd_resize() and Image::resize() continue to take
raw size. The user has to constantly keep these domains in mind.
Saying that resize must be done without encryption loaded is not an
answer because shrinking a clone that has snapshots involves copying up
objects in the affected range (identical to flattening). In addition,
even if a clone doesn't have snapshots, shrinking it to a size that
isn't an object boundary is going to involve a copyup for the victim
object as well.
To avoid subtle data corruption on shrink, treat resize operation the
same as flatten operation (including on the CLI).
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Currently it's done in FormatRequest but not in LoadRequest. However
an image can be deep copied or exported and imported with a different
stripe pattern such that an area boundary would fall in the middle of
an object.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Currently it's done in FormatRequest but not in LoadRequest. However
an image can be shrunk to a size such that encryption can loaded (i.e.
enough of the header is still present) but nothing else can, breaking
implicit assumptions all around.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Proceed with formatting an image even if all space would be consumed by
the crypto header. There is no reason to be strict here since we allow
creating zero-sized images as well as shrinking any image to 0.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(Temporarily) shutting down crypto can lead to data corruption in the
face of concurrent I/O, especially when flatten operation is proxied to
the remote lock owner. This was added to be able to read, optionally
modify and write crypto header without it being subjected to remapping
and encryption itself. read_header() and write_header() now achieve
that by specifying CRYPTO_HEADER area explicitly.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This method doesn't propagate area. Since its only user is
CryptoObjectDispatch which is now applied only to DATA area,
move get_file_offset() there to avoid misuse in the future.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Objects in CRYPTO_HEADER area should not be subjected to encryption.
Unit tests needed adjustment because MockCryptoInterface is configured
with DATA_OFFSET = 4 * 1024 * 1024, thus disqualifying object 0.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
- readahead and PWL cache are limited to DATA area as explained in
the previous commit
- DATA area is assumed for the journal as encryption can't be used
with journaling anyway
To postpone the churn associated with passing area through
ImageDispatchInterface (where only WriteLogImageDispatch and
ImageDispatch care), add a new image dispatch flag.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
- DATA area is assumed at the API layer as there is no way to pass
an area
- DATA area is assumed by ImageWriteback because PWL cache persists
image extents as provided by the user without any kind of designator
and therefore can be active only in either area
- luks::FlattenRequest operates on CRYPTO_HEADER area
The passed area is acted upon in ImageDispatchSpec constructor in the
next commit.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Note that, as suggested by extents_to_file() signature, all returned
image extents would pertain to the same area. This means that an area
boundary must coincide with an object boundary.
luks::FormatRequest is actually more strict: crypto header area size is
set to a multiple of stripe period (i.e. one or more whole objects).
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Since remap in either direction can really be done only once, iterating
through image dispatch layers in ImageDispatcher::remap_extents() makes
no sense. For now, just replace the iteration with CryptoImageDispatch
lookup.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
These are still taking off and len separately which is inconsistent
with the rest of ImageDispatchSpec and also ImageDiscardRequest and
ImageWriteSameRequest.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
image_extents is already taken by rvalue reference.
CopyupRequest::create() callers are prepared for the move.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Commit e0da2a4e8c ("qa/workunits/rbd: Add test to list snapshots of
consistency group") added bash-specific syntax.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Directly comparing the dicts doesn't work since the
"created" field was added in. We should instead make use
of the existing Devices equality function.
Fixes: https://tracker.ceph.com/issues/57999
Signed-off-by: Adam King <adking@redhat.com>
