doc: Fix Markdown MD032 linter warnings

of logical blocks for write operation.

New zone-related fields were added to the result of the `get_bdevs` RPC call:

 - `zoned`: indicates whether the device is zoned or a regular

   block device

 - `zone_size`: number of blocks in a single zone

 - `max_open_zones`: maximum number of open zones

 - `optimal_open_zones`: optimal number of open zones

The `zoned` field is a boolean and is always present, while the rest is only available for zoned

bdevs.

for which the memory is contiguous in the physical memory address space.

The following functions were removed:

 - spdk_pci_nvme_device_attach()

 - spdk_pci_nvme_enumerate()

 - spdk_pci_ioat_device_attach()

They were replaced with generic spdk_pci_device_attach() and spdk_pci_enumerate() which

require a new spdk_pci_driver object to be provided. It can be one of the following:

 - spdk_pci_nvme_get_driver()

 - spdk_pci_ioat_get_driver()

 - spdk_pci_virtio_get_driver()

### RPC

The following RPC commands deprecated in the previous release are now removed:

 - construct_virtio_user_scsi_bdev

 - construct_virtio_pci_scsi_bdev

 - construct_virtio_user_blk_bdev

### Virtio

The following RPC commands have been deprecated:

 - construct_virtio_user_scsi_bdev

 - construct_virtio_pci_scsi_bdev

 - construct_virtio_user_blk_bdev

Added jsonrpc-client C library intended for issuing RPC commands from applications.

Added API enabling iteration over JSON object:

 - spdk_json_find()

 - spdk_json_find_string()

 - spdk_json_find_array()

New API functions that accept I/O parameters in units of blocks instead of bytes

have been added:

- spdk_bdev_read_blocks(), spdk_bdev_readv_blocks()

- spdk_bdev_write_blocks(), spdk_bdev_writev_blocks()

- spdk_bdev_write_zeroes_blocks()

Support for SPDK performance analysis has been added to Intel® VTune™ Amplifier 2018.

This analysis provides:

- I/O performance monitoring (calculating standard I/O metrics like IOPS, throughput, etc.)

- Tuning insights on the interplay of I/O and compute devices by estimating how many cores

  would be reasonable to provide for SPDK to keep up with a current storage workload.

in app/iscsi_tgt and a documented configuration file can be found at etc/spdk/spdk.conf.in.

This release also significantly improves the existing NVMe over Fabrics target.

  - The configuration file format was changed, which will require updates to

    any existing nvmf.conf files (see `etc/spdk/nvmf.conf.in`):

    - `SubsystemGroup` was renamed to `Subsystem`.

This release also adds one new feature and provides some better examples and tools

for the NVMe driver.

  - The Weighted Round Robin arbitration method is now supported. This allows

    the user to specify different priorities on a per-I/O-queue basis.  To

    enable WRR, set the `arb_mechanism` field during `spdk_nvme_probe()`.

This is the initial open source release of the Storage Performance Development Kit (SPDK).

Features:

- NVMe user-space driver

- NVMe example programs

  - `examples/nvme/perf` tests performance (IOPS) using the NVMe user-space driver

handling overhead.

The development kit currently includes:

* [NVMe driver](http://www.spdk.io/doc/nvme.html)

* [I/OAT (DMA engine) driver](http://www.spdk.io/doc/ioat.html)

* [NVMe over Fabrics target](http://www.spdk.io/doc/nvmf.html)

In order to start a SPDK app linked with SPDK shared libraries, make sure

to do the following steps:

- run ldconfig specifying the directory containing SPDK shared libraries

- provide proper `LD_LIBRARY_PATH`

As mentioned earlier, Blobstore can share a single thread with an application or the application

can define any number of threads, within resource constraints, that makes sense.  The basic considerations that must be

followed are:

* Metadata operations (API with MD in the name) should be isolated from each other as there is no internal locking on the

   memory structures affected by these API.

* Metadata operations should be isolated from conflicting IO operations (an example of a conflicting IO would be one that is

There are two extent representations on-disk, dependent on `use_extent_table` (default:true) opts used

when creating a blob.

* **use_extent_table=true**: EXTENT_PAGE descriptor is not part of linked list of pages. It contains extents

  that are not run-length encoded. Each extent page is referenced by EXTENT_TABLE descriptor, which is serialized

  as part of linked list of pages.  Extent table is run-length encoding all unallocated extent pages.

~~~

And for the most part the following conventions are followed throughout:

* functions beginning with an underscore are called internally only

* functions or variables with the letters `cpl` are related to set or callback completions

The address map and valid map are, along with a several other things (e.g. UUID of the device it's

part of, number of surfaced LBAs, band's sequence number, etc.), parts of the band's metadata. The

metadata is split in two parts:

 * the head part, containing information already known when opening the band (device's UUID, band's

   sequence number, etc.), located at the beginning blocks of the band,

 * the tail part, containing the address map and the valid map, located at the end of the band.

Similar to other bdevs, the FTL bdevs can be created either based on JSON config files or via RPC.

Both interfaces require the same arguments which are described by the `--help` option of the

`bdev_ftl_create` RPC call, which are:

 - bdev's name

 - base bdev's name (base bdev must implement bdev_zone API)

 - UUID of the FTL device (if the FTL is to be restored from the SSD)

To emulate an Open Channel device, QEMU expects parameters describing the characteristics and

geometry of the SSD:

 - `serial` - serial number,

 - `lver` - version of the OCSSD standard (0 - disabled, 1 - "1.2", 2 - "2.0"), libftl only supports

   2.0,

```

In order to create FTL on top Open Channel SSD, the following steps are required:

1) Attach OCSSD NVMe controller

2) Create OCSSD bdev on the controller attached in step 1 (user could specify parallel unit range

and create multiple OCSSD bdevs on single OCSSD NVMe controller)

A logical volume has a UUID and a name for its identification.

The UUID of the logical volume is generated on creation and it can be unique identifier.

The alias of the logical volume takes the format _lvs_name/lvol_name_ where:

* _lvs_name_ is the name of the logical volume store.

* _lvol_name_ is specified on creation and can be renamed.