The intents of these arrays was to keep track in the
bdev layer of all base<->virtual bdev relationships -
i.e. which member disk bdevs make up a RAID bdev,
which logical volume bdevs are associated with a
bdev that contains an lvolstore, etc.
Currently none of this is used however. And trying
to keep track in the bdev layer instead of asking
the bdev modules for the relationships has a number
of complications. Early one, we tried to do this
with TAILQs - but that doesn't work since this can't
be done with a single TAILQ_ENTRY in the bdev
structures. So we moved to arrays - that works a bit
better, but then the pointer arrays have to be
realloc'd which isn't ideal.
The biggest problem though with these arrays is that
they held bdev pointers - not bdev descriptor pointers.
It's not really valid to access bdevs without a
descriptor - the descriptors are what make sure active
references are accounted for when a bdev is hotplugged.
Of course the bdev layer knows when a bdev is getting
removed and could go and do the updates to these
arrays separately - but that just seems very convoluted.
So for now just remove these arrays completely. If
there is a future need for the bdev layer to
understand relationships between bdevs, we can add
module APIs so that the generic layer can ask
the modules about the relationships.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I99ef1068240bff1262f64f234260cf2fb44df51d
Reviewed-on: https://review.gerrithub.io/420932
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: GangCao <gang.cao@intel.com>
During spdk_bdev_init, examine_config is called.
This call can claim bdev synchronously, based on
configuration. On spdk_bdev_start if none module
claimed bdev, examine_disk is called and can
perform I/O before claiming bdev.
Signed-off-by: Piotr Pelplinski <piotr.pelplinski@intel.com>
Change-Id: I1448dd368cf3a24a5daccab387d7af7c3d231127
Reviewed-on: https://review.gerrithub.io/413913
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Maciej Szwed <maciej.szwed@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
For application like vhost/iSCSI target/NVMe-oF target/etc,
a new section as below can be added for the QoS rate limiting.
[QoS]
Limit_IOPS Malloc0 100000
Limit_IOPS Nvme0n1 500000
Also added a sample change at test/lib/bdev/bdev.conf.in
Change-Id: I7c7d951fbe1352ca2571f135c657bc4fa43b56c7
Signed-off-by: GangCao <gang.cao@intel.com>
Reviewed-on: https://review.gerrithub.io/393221
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
SPKD base bdev might be part of multiple vbdevs. The same is true in
reverse direction. So consider folowing scenario:
bdev3 bdev4 bdev5
| | |
+-+--+ + +--+--+
/ \ | / \
bdev0 bdev1 bdev2
In current implementation bdev0/1/2 will apear as base base for
bdev3/4/5 which is obviously wrong.
This patch try to address this issue.
Change-Id: Ic99c13c8656ceb597aba7e41ccb2fa8090b4f13b
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-on: https://review.gerrithub.io/405104
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
This file is accessed by files in multiple directories under test.
Change-Id: I634481fb58eab5c097aaece5289f88e531954fcb
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/404976
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Write information needed to recreate each bdev.
Change-Id: I3d2b24fd4aaa8b98ec558d864cc28b55a899452f
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-on: https://review.gerrithub.io/401217
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
This better matches the style in the rest of SPDK.
No functional change - this is a pure find/replace of
spdk_bdev_module_if to spdk_bdev_module. Instances of this struct will
be renamed in another patch.
Change-Id: I3f6933c8a366e625fc3a1b6401aee26ee03ba69c
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-on: https://review.gerrithub.io/403368
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Currently SPDK_BDEV_MODULE_REGISTER() take many parameters. Extending it
(eg for incoming JSON configuration dump/load) is quite challenging and
error prone. As we are already here in next patches, rework this macro
to take one parameter - the pointer to struct spdk_bdev_module_if.
This patch also remove following macros:
SPDK_GET_BDEV_MODULE - this is not really needed, to find module outside
module translation unit use spdk_bdev_module_list_find()
SPDK_BDEV_MODULE_ASYNC_INIT and SPDK_BDEV_MODULE_ASYNC_FINI - replaced
by bool fields in spdk_bdev_module_if struct.
Change-Id: Ief88e023fbbaee7d5402c838dbecbdffd4dfb259
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Reviewed-on: https://review.gerrithub.io/402883
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Change-Id: If19c263d184c1eaab12950ba0baa05e7f3aea6e0
Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-on: https://review.gerrithub.io/401729
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
