ceph-nvmeof icon indicating copy to clipboard operation
ceph-nvmeof copied to clipboard

RBD image sizing

Open baum opened this issue 9 months ago • 1 comments

RBD image sizing

The current implementation permits arbitrary image sizes with a resolution down to a single byte.

SPDK and CEPH

As per the RBD image resizing logic in SPDK, the new image size must be a multiple of 1024 * 1024 bytes. Furthermore, for guidance on image sizing, please consult the Ceph RBD manual, which specifies the following:

-s size-in-M/G/T, --size size-in-M/G/T
    Specifies the size of the new RBD image or the new size of the existing RBD image in M/G/T.
    If no suffix is given, the unit M is assumed.

ceph-nvmeof gateway change

Restrict the possibility of defining arbitrary image sizes down to a single byte, both at the gRPC and CLI levels, during image creation and resizing. Adhere to the sizing convention used in Ceph, where size-in-M/G/T is specified. If no suffix is provided, the unit M should be assumed.

baum avatar May 08 '24 06:05 baum

The resize uses a value in MiBs. This means that and value passed to SPDK must be aligned to 1024*1024. If we pass 2 to SPDK it actually means 2MiB. The CLI converts the value passed in the command line to MiBs. This means the size value passed by the user might get truncated. I will add a test to fail the CLI in case the value is not properly aligned. This will make sure there will be no difference between the user usage and the actual size passed to SPDK.

While the resize only works in MiBs, this is not the case when we create an image for a namespace. Here we call the RBD API which gets a size value in bytes. This means we can create an image which is 100 bytes big. I will add a test in the CLI and gRPC to force this value to be aligned to 1024*1024. Notice that while the rbd command line will handle a size with no units as MiBs, this is not the case for the RBD API which accepts any size in bytes.

gbregman avatar May 08 '24 10:05 gbregman