On 01/26/2018 09:30 AM, Javier Gonzalez wrote:
On 25 Jan 2018, at 22.02, Matias Bjørling <mb@xxxxxxxxxxx> wrote:
On 01/25/2018 04:26 PM, Javier Gonzalez wrote:
Hi,
There are some topics that I would like to discuss at LSF/MM:
- In the past year we have discussed a lot how we can integrate the
Open-Channel SSD (OCSSD) spec with zone devices (SMR). This
discussion is both at the interface level and at an in-kernel level.
Now that Damien's and Hannes' patches are upstreamed in good shape,
it would be a good moment to discuss how we can integrate the
LightNVM subsystem with the existing code.
The ZBC-OCSSD patches
(https://github.com/OpenChannelSSD/linux/tree/zbc-support) that I made
last year is a good starting point.
Yes, this patches is a good place to start, but as mentioned below, they
do not address how we would expose the parallelism on report_zone.
The way I see it, zone-devices impose write constrains to gain capacity;
OCSSD does that to enable the parallelism of the device.
Also capacity for OCSSDs, as most raw flash is exposed. It is up to the
host to decide if over-provisioning is needed.
This then can
be used by different users to either lower down media wear, reach a
stable state at the very early stage or guarantee tight latencies. That
depends on how it is used. We can use an OCSSD as a zone-device and it
will work, but it is coming back to using an interface that will narrow
down the OCSSD scope (at least in its current format).
Specifically, in ALPSS'17
we had discussions on how we can extend the kernel zoned device
interface with the notion of parallel units that the OCSSD geometry
builds upon. We are now bringing the OCSSD spec. to standarization,
but we have time to incorporate feedback and changes into the spec.
Which spec? the OCSSD 2 spec that I have copyright on? I don't believe
it has been submitted or is under consideration to any standards body
yet and I don't currently plan to do that.
You might have meant "to be finalized". As you know, I am currently
soliciting feedback and change requests from vendors and partners with
respect to the specification and is planning on closing it soon. If
CNEX is doing their own new specification, please be open about it,
and don't put it under the OCSSD name.
As you know, there is a group of cloud providers and vendors that is
starting to work on the standarization process with the current state of
the 2.0 spec as the staring point - you have been part of these
discussions... The goal for this group is to collect the feedback from
all parties and come up with a spec. that is useful and covers cloud
needs. Exactly for - as you imply -, not to tie the spec. to an
organization and/or individual. My hope is that this spec is very
similar to the OCSSD 2.0 that _we_ all have worked hard on putting
together.
Yes, that is my point. The workgroup device specification you are
discussing may or may not be OCSSD 2.0 similar/compatible and is not
tied to the process that is currently being run for the OCSSD 2.0
specification. Please keep OCSSD out of the discussions until the device
specification from the workgroup has been completed and made public.
Hopefully the device specification turns out to be OCSSD 2.0 compatible
and the bits can be added to the 2.0 (2.1) specification. If not, it has
to be stand-alone, with its own implementation.
Later on, we can try to to checks on lba "batches", defined by this same
write restrictions. But you are right that having a fully random lba
vector will require individual checks and that is both expensive and
intrusive. This can be isolated by flagging the nature of the bvec,
something ala (sequential, batched, random).
I think it must still be checked. One cannot trust that the LBAs are as
expected. For example, the case where LBAs are out of bounds and
accesses another partition.
For example supported natively in the NVMe specification.
Then we agree that aiming at a stardard body is the goal, right?
Vector I/O is orthogonal to proposing a zone/ocssd proposal to the NVMe
workgroup.
