OK, I see. Will include these changes in next version. 2016-01-28 17:09 GMT+08:00 Matias Bjørling <mb@xxxxxxxxxxx>: > On 01/28/2016 09:50 AM, Wenwei Tao wrote: >> 2016-01-27 17:44 GMT+08:00 Matias Bjørling <mb@xxxxxxxxxxx>: >>> On 01/26/2016 01:33 PM, Wenwei Tao wrote: >>>> When create a target, we specify the begin lunid and >>>> the end lunid, and get the corresponding continuous >>>> luns from media manager, if one of the luns is not free, >>>> we failed to create the target, even if the device's >>>> total free luns are enough. >>>> >>>> So add non-continuous lun target creation support, >>>> thus we can improve the backend device's space utilization. >>>> Signed-off-by: Wenwei Tao <ww.tao0320@xxxxxxxxx> >>>> --- >>>> Changes since v1: >>>> -use NVM_FIXED instead NVM_C_FIXED in gennvm_get_lun >>>> -add target creation flags check >>>> -rebase to v4.5-rc1 >>>> >>>> drivers/lightnvm/core.c | 36 ++++--- >>>> drivers/lightnvm/gennvm.c | 42 ++++++++- >>>> drivers/lightnvm/rrpc.c | 215 +++++++++++++++++++++++++++--------------- >>>> drivers/lightnvm/rrpc.h | 6 +- >>>> include/linux/lightnvm.h | 24 ++++- >>>> include/uapi/linux/lightnvm.h | 3 + >>>> 6 files changed, 229 insertions(+), 97 deletions(-) >>>> >>> >>> Hi Wenwei, >>> >>> I did some digging on the patch and changed the interface to a >>> reserve/release interface. I also removed the logic to dynamically >>> select another lun than the one requested. >>> >>> A couple of questions: >>> >>> 1. The rrpc_lun->rev_lock and rev_trans_map change; this might be for >>> another patch, and it isn't directly related to continuous mapping? >> >> rrpc_lun->rev_lock and rev_trans_map change is related to >> non-continuous mapping, it's not directly related to continuous >> mapping. >> Put this change in another patch along with non-continuous mapping >> support and this patch would be only add reserve/release thing, is >> that your suggestion? > > Yes, that would be great. Then we keep it separate. I'll like to do some > benchmarks with the patch on and off, to see the performance difference. > >> >>> 2. Instead of dynamically assigning new luns when not available, what >>> about taking a list of lun ids instead? >>> >> >> Seems you prefer user make the choice ? > > Yes, I want it to be deterministic. For example, if we do it > dynamically, the user might first allocate 2-4, and then allocate 1-3 , > which will actually allocate 0,1,5. Then later, a user tries to allocate > on 0, and instead gets returned 6. It quickly makes it difficult to use. > >> But the target creation can still fail if one of the list lun ids is >> not available although there may be enough free luns. > > Agree, the user would have to look up the free luns and then resubmit > the target allocation. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
