671b77e5cd
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> |
||
|---|---|---|
| .. | ||
| bdev_raid.c | ||
| bdev.c | ||
| gpt | ||
| mt | ||
| part.c | ||
| pmem | ||
| scsi_nvme.c | ||
| vbdev_lvol.c | ||
| Makefile | ||