doc/blob: fix typo errors

Change-Id: I19f69a880ff9237aa254da57300c8611252da231
Signed-off-by: Chen Zhenghua <chen.zhenghua@zte.com.cn>
Reviewed-on: https://review.gerrithub.io/422819
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
This commit is contained in:
Chen Zhenghua 2018-08-20 20:38:07 +08:00 committed by Changpeng Liu
parent 6deac3e660
commit b07d3bd2bd

View File

@ -183,7 +183,7 @@ When the Blobstore is initialized, there are multiple configuration options to c
options and their defaults are:
* **Cluster Size**: By default, this value is 1MB. The cluster size is required to be a multiple of page size and should be
selected based on the applications usage model in terms of allocation. Recall that blobs are made of up clusters so when
selected based on the applications usage model in terms of allocation. Recall that blobs are made up of clusters so when
a blob is allocated/deallocated or changes in size, disk LBAs will be manipulated in groups of cluster size. If the
application is expecting to deal with mainly very large (always multiple GB) blobs then it may make sense to change the
cluster size to 1GB for example.
@ -230,7 +230,7 @@ indicate and error. Synchronous calls will typically return an error value if ap
### Asynchronous API
Asynchronous callbacks will return control not immediately, but at the point in execution where no
more forward progress can be made without blocking. Therefore, no assumptions can be made be made about the progress of
more forward progress can be made without blocking. Therefore, no assumptions can be made about the progress of
an asynchronous call until the callback has completed.
### Xattrs
@ -271,7 +271,7 @@ does nothing more than demonstrate the very basic API. Although Blobstore is opt
a RAM disk (malloc) back-end so that it can be executed easily in any development environment. The malloc back-end
is a `bdev` module thus this example uses not on the SPDK Framework but the `bdev` layer as well.
* **Hello NVME Blob**: `hello_nvme_blob.c` is the non-bdev version of `hello_blob.c`and simply shows how an
* **Hello NVME Blob**: `hello_nvme_blob.c` is the non-bdev version of `hello_blob.c` and simply shows how an
application can directly integrate Blobstore with the SPDK NVMe driver without using the `bdev` layer at all.
* **CLI**: The `blobcli.c` example is command line utility intended to not only serve as example code but as a test
@ -280,7 +280,7 @@ SPDK Framework and the `bdev` layer but offers multiple modes of operation to ac
command mode, it accepts single-shot commands which can be a little time consuming if there are many commands to
get through as each one will take a few seconds waiting for DPDK initialization. It therefore has a shell mode that
allows the developer to get to a `blob>` prompt and then very quickly interact with Blobstore with simple commands
that include the ability to import/export blobs from/to regular files. Lastly there is a a scripting mode to automate
that include the ability to import/export blobs from/to regular files. Lastly there is a scripting mode to automate
a series of tasks, again, handy for development and/or test type activities.
## Configuration {#blob_pg_config}