Re: [RFC PATCH 2/2] lightnvm: add non-continuous lun target creation support

[Wenwei Tao]

2016-01-21 15:53 GMT+08:00 Matias BjÃrling <mb@xxxxxxxxxxx>:
> On 01/21/2016 08:44 AM, Wenwei Tao wrote:
>> 2016-01-20 21:19 GMT+08:00 Matias BjÃrling <mb@xxxxxxxxxxx>:
>>> On 01/15/2016 12:44 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.
>>>
>>> A couple of questions:
>>>
>>> A user inits lun 3-4 and afterwards another 1-6, then only 1,2,5,6 would
>>> be initialized?
>>>
>>> What about the case where init0 uses 3-4, and init1 uses 1-6, and would
>>> share 3-4 with init0?
>>>
>>> Would it be better to give a list of LUNs as a bitmap, and then try to
>>> initialize on top of that? with the added functionality of the user may
>>> reserve luns (and thereby reject others attempting to use them)
>>>
>>
>> I'm not quite understand the bitmap you mentioned.
>> This patch do have a bitmap : dev->lun_map and the target creation is
>> on top of this bitmap.
>>
>> The way how a target gets its LUNs is based on its creation flags.
>> If NVM_C_FIXED is set, this means the target wants get its LUNs
>> exactly as it specifies from lun_begin to lun_end, if any of them are
>> occupied by others, the creation fail.
>> If NVM_C_FIXED is not set, the target will get its LUNs from free LUNs
>> between  0 and dev->nr_luns, there is no guarantee that final LUNs are
>> continuous.
>>
>> For the first question, if NVM_C_FIXED is used second creation would
>> be fail since 3-4 are already used, otherwise it will success if we
>> have enough free LUNs left, but the final LUNs may not from 1 to 6,
>> e.g. 1, 2, 5, 6, 7, 11.
>>
>> For the second question, from explanation above we know that sharing
>> LUNs would not happen in current design.
>
> This is an interesting discussion. This could boil down to a device
> supporting either a dense or sparse translation map (or none).
>
> With a dense translation map, there is a 1-to-1 relationship between
> lbas and ppas.
>
> With a sparse translation map (or no translation map, handled completely
> by the host), we may share luns.
>
> For current implementations, a dense mapping is supported. I wonder the
> cost of implementing a sparse map (e.g. b-tree structure) on a device is
> a good design choice.
>
> If the device supports sparse mapping, then we should add another bit to
> the extension bitmap, and then allow luns to shared. In the current
> case, we should properly just deny luns to be shared between targets.
>
> How about extending the functionality to take a bitmap of luns, which
> defines the luns that we like to map. Do the necessary check if any of
> them is in use, and then proceed if all is available?
>

Currently a bitmap of luns already added into nvm_dev, every time we
map the luns we check the bitmap.
I don't quite understand why we need to add another bitmap?

> That'll remove the ambiguity from selection luns, and instead enable the
> user to make the correct decision up front?
>
>
>
>