On 08/03/2018 02:55 PM, Javier Gonzalez wrote:
On 3 Aug 2018, at 14.43, Matias Bjørling <mb@xxxxxxxxxxx> wrote:
On 08/03/2018 02:40 PM, Javier Gonzalez wrote:
On 3 Aug 2018, at 14.37, Matias Bjørling <mb@xxxxxxxxxxx> wrote:
On 08/03/2018 02:16 PM, Javier Gonzalez wrote:
On 3 Aug 2018, at 10.54, Matias Bjørling <mb@xxxxxxxxxxx> wrote:
A 1.2 device is able to manage the logical to physical mapping
table internally or leave it to the host.
A target only supports one of those approaches, and therefore must
check on initialization. Move this check to core to avoid each target
implement the check.
Signed-off-by: Matias Bjørling <mb@xxxxxxxxxxx>
---
I see where you want to go with these changes, but the way targets are
layered on top of the LightNVM subsystem does not align with it.
LightNVM can support different OCSSD versions and capabilities, but that
does not mean that a target (e.g., pblk) does. The way I see it, core
should only check for (i) the drive to expose itself in a known revision
and (ii) the reported structures to be consistent. However, specific
functionality is not for core to check upo.
Why try to initialize a target, if we already know that it is incompatible?
Yes, that is my point. But the one who knows if the targets supports
something or not is the target, not the subsystem. Here, you are making
an assumption knowing the pblk requires the L2P on the host, but that
could change in the future...
I don't believe it can. It is not supported by the 2.0 specification.
1.2 is legacy.
Ja... We both know that people is using 1.2 variants out there...
Yes, I'm not saying that. I'm saying the spec 1.2 has been deprecated by
2.0 and no longer developed, and I'm not going to move that brainfart
into the 2.0 spec :)
I understand this from the perspective when checking for un-even
configurations using the geometry. But this is a spec incompatibility,
which I don't think the target should care about.
I see the point of not having this check in pblk since we know that we
are moving towards 2.0 and leaving 1.2 as legacy/not-upstream. But does
it really make sense to fail LightNVM on a 1.2 capability that is spec.
compliant? For all we know people could have this and use it from user
space or through an internal target.
It only fails on target creation, not on disk initialization. The disk
will be up so user-space and targets that implements. Is that a problem?
