SPDK August 2021

spdk@lists.01.org

4 participants
2 discussions

On the resize of bdevs with iSCSI initiator backend or NVMf backend

by liushengchao02＠meituan.com

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.

1 month, 1 week

3
3
0 / 0

Clarification regarding VFIO driver bind in the setup.sh

by chandanga＠google.com

I needed a clarification regarding the VFIO setup script for SPDK (https://github.com/spdk/spdk/blob/master/scripts/setup.sh). In the linux_bind_driver() method, we have the following lines: echo "$ven_dev_id" > "/sys/bus/pci/drivers/$driver_name/new_id" 2> /dev/null || true echo "$bdf" > "/sys/bus/pci/drivers/$driver_name/bind" 2> /dev/null || true I'm wondering if both steps are necessary? It looks like if we set the vendor_id, device_id into "/sys/bus/pci/drivers/vfio-pci/new_id", this will automatically assign all the VFs (which are not assigned to the NVMe driver) to the VFIO driver. Hence, the second line (echoing the $bdf to the bind file) becomes redundant. Is this correct? Any reason why both of these steps are required? Thanks.

1 month, 1 week

2
1
0 / 0

← Newer
1
Older →

2021

2020

2019

2018

2017

2016

SPDK August 2021