> On 22 Feb 2018, at 13.22, Matias Bjørling wrote:
>
> On 02/22/2018 08:44 AM, Javier Gonzalez wrote:
>>> On 22 Feb 2018, at 08.25, Matias Bjørling wrote:
>>>
>>> On 02/21/2018 10:26 AM, Javier González wrote:
Currently, the device geometry is stored redundantly in the nvm_id and
nvm_
On 02/22/2018 08:44 AM, Javier Gonzalez wrote:
On 22 Feb 2018, at 08.25, Matias Bjørling wrote:
On 02/21/2018 10:26 AM, Javier González wrote:
Currently, the device geometry is stored redundantly in the nvm_id and
nvm_geo structures at a device level. Moreover, when instantiating
targets on
> On 22 Feb 2018, at 08.25, Matias Bjørling wrote:
>
> On 02/21/2018 10:26 AM, Javier González wrote:
>> Currently, the device geometry is stored redundantly in the nvm_id and
>> nvm_geo structures at a device level. Moreover, when instantiating
>> targets on a specific number of LUNs, these str
On 02/21/2018 10:26 AM, Javier González wrote:
Currently, the device geometry is stored redundantly in the nvm_id and
nvm_geo structures at a device level. Moreover, when instantiating
targets on a specific number of LUNs, these structures are replicated
and manually modified to fit the instance
Currently, the device geometry is stored redundantly in the nvm_id and
nvm_geo structures at a device level. Moreover, when instantiating
targets on a specific number of LUNs, these structures are replicated
and manually modified to fit the instance channel and LUN partitioning.
Instead, create a