All of lore.kernel.org
 help / color / mirror / Atom feed
* [SPDK] Re: On the resize of bdevs with iSCSI initiator backend or NVMf backend
@ 2021-08-18  4:07 Cao, Gang
  0 siblings, 0 replies; 3+ messages in thread
From: Cao, Gang @ 2021-08-18  4:07 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Hi Shengchao,

The resize capability is also relying on the backend supporting device. Take iSCSI device as example, if it could do the dynamic resize (increasing the capacity), the we could add a bdev_iscsi_resize() function. Once the backend device is increased for its capacity, then we could call the spdk_bdev_notify_blockcnt_change() function to trigger the notification.

You may also refer to the bdev_rbd_resize() function and related RPC operation to trigger the resize. So basically if the backend device could do the resize at runtime (like SPDK LVOL, Ceph RBD), then we could easily support the runtime resize.

Thanks,
Gang

-----Original Message-----
From: liushengchao02(a)meituan.com <liushengchao02(a)meituan.com> 
Sent: Wednesday, August 18, 2021 11:31
To: spdk(a)lists.01.org
Subject: [SPDK] On the resize of bdevs with iSCSI initiator backend or NVMf backend

Hello,

We are studying SPDK and preparing for remote storage applications.

After testing, I find that bdevs created by bdev_iscsi_create or bdev_nvme_attach_controller can't resize accordingly when the connected remote target block devices have been resized online.

However, when using 'nvme connect' or 'iscsiadmin' commands, the connected block devices can resize accordingly as remote storage resizes and local users can use the connected remote storage without interruption (with the help of resize2fs or xfs_growfs).

I learned that SPDK support resize of bdevs with ceph rbd or logical volume beckend (i.e. bdevs created by bdev_rbd_create and bdev_lvol_create).

Dose SPDK support or will support the resize of iSCSI and NVMf backend when the connected remote target has been resized?

Thank you very much.
_______________________________________________
SPDK mailing list -- spdk(a)lists.01.org
To unsubscribe send an email to spdk-leave(a)lists.01.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [SPDK] Re: On the resize of bdevs with iSCSI initiator backend or NVMf backend
@ 2021-08-18  6:22 liushengchao02
  0 siblings, 0 replies; 3+ messages in thread
From: liushengchao02 @ 2021-08-18  6:22 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

Hi, Jim and Gang,

Thank you for your replies. We will do some further testings and file some issues in Github when we finish testing.

Regargs,
Shengchao Liu

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [SPDK] Re: On the resize of bdevs with iSCSI initiator backend or NVMf backend
@ 2021-08-18  4:53 Harris, James R
  0 siblings, 0 replies; 3+ messages in thread
From: Harris, James R @ 2021-08-18  4:53 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

Hi Shengchao,

The bdev nvme module detects namespace size changes based on AER completions and reports them to the bdev layer using spdk_bdev_notify_blockcnt_change().  If you are seeing different behavior, could you file an issue with specific repro steps and the SPDK version you are testing on https://github.com/spdk/spdk/issues?

For iSCSI, the bdev module does not currently detect and report resizes.  It could be added, but no one is working on that currently.  This could also be filed in the GitHub issues database as an enhancement request.

Regards,

Jim

On 8/17/21, 9:07 PM, "Cao, Gang" <gang.cao(a)intel.com> wrote:

    Hi Shengchao,

    The resize capability is also relying on the backend supporting device. Take iSCSI device as example, if it could do the dynamic resize (increasing the capacity), the we could add a bdev_iscsi_resize() function. Once the backend device is increased for its capacity, then we could call the spdk_bdev_notify_blockcnt_change() function to trigger the notification.

    You may also refer to the bdev_rbd_resize() function and related RPC operation to trigger the resize. So basically if the backend device could do the resize at runtime (like SPDK LVOL, Ceph RBD), then we could easily support the runtime resize.

    Thanks,
    Gang

    -----Original Message-----
    From: liushengchao02(a)meituan.com <liushengchao02(a)meituan.com> 
    Sent: Wednesday, August 18, 2021 11:31
    To: spdk(a)lists.01.org
    Subject: [SPDK] On the resize of bdevs with iSCSI initiator backend or NVMf backend

    Hello,

    We are studying SPDK and preparing for remote storage applications.

    After testing, I find that bdevs created by bdev_iscsi_create or bdev_nvme_attach_controller can't resize accordingly when the connected remote target block devices have been resized online.

    However, when using 'nvme connect' or 'iscsiadmin' commands, the connected block devices can resize accordingly as remote storage resizes and local users can use the connected remote storage without interruption (with the help of resize2fs or xfs_growfs).

    I learned that SPDK support resize of bdevs with ceph rbd or logical volume beckend (i.e. bdevs created by bdev_rbd_create and bdev_lvol_create).

    Dose SPDK support or will support the resize of iSCSI and NVMf backend when the connected remote target has been resized?

    Thank you very much.
    _______________________________________________
    SPDK mailing list -- spdk(a)lists.01.org
    To unsubscribe send an email to spdk-leave(a)lists.01.org
    _______________________________________________
    SPDK mailing list -- spdk(a)lists.01.org
    To unsubscribe send an email to spdk-leave(a)lists.01.org


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-08-18  6:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-18  4:07 [SPDK] Re: On the resize of bdevs with iSCSI initiator backend or NVMf backend Cao, Gang
2021-08-18  4:53 Harris, James R
2021-08-18  6:22 liushengchao02

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.