This will allow us to keep track of compatibility issues on a
per-library basis.
Change-Id: Ib0c796adb1efe1570212a503ed660bef6f142b6e
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1067
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
In the reduce_dev_destroy case, we were not calling
alloc_zero_buf in the load path because of a built in short circuit.
This resulted in us decrementing the g_vol_count variable past 0 in
cases where we were destroying a reduce volume that we had already
freed. This resulted in us failing to allocate the g_zero_buf the next
time we loaded a reduce volume.
Change-Id: I429cbac1454bdcda502038af659d5302627ecab2
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/478127
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Instead of arbitrarily selecting the chunk size of the first device we
attach, we should make it an arbitrarily large value that can fit larger
chunks.
Change-Id: I4e8b54cbae62607e352402025ca3dae01ebfbb51
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/478126
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
We also need to make sure that the deconm_iov is large enough to handle
all of the iovs we claim to support plus 2, one for offset into the
chunk when doing writes and one for the remainder.
Plus a unittest to demonstrate the possible out of bounds error in the
library.
Change-Id: I7747ad39f76e50f25ecf5168b01e046f71fa0ea8
Signed-off-by: Seth Howell <seth.howell@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/478125
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
First is a patch series that enables an application to delete
a compression vbdev when the volume is missing it's pmem file.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: Ida639d2c231833f23131926d442ad430ec903e03
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/465805
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Changed to 17 from 32 per conversation with Jim and moved to
header file so it can be shared with the vbdev module.
Change-Id: Ic516b6466bf21d21d8073e9180deaa9929c6b742
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/463368
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Broadcom SPDK FC-NVMe CI <spdk-ci.pdl@broadcom.com>
If a write operation comes in and is not a read-modify-write but
we don't end up compressing the data (because of either error or
we decide the compression ratio isn't good enough) then we not
only need to copy the data to the host buffers but we need to
zero any offset and/or remainder in the decomp scratch buffer.
Change-Id: Ifb2235507826f9ef1110dd9dbaf88045d8979e7c
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/463337
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Had used a few different means to determine if there's space
remaining in a chunk after accounting for offset and host data,
just making them all consistent. Nothing functionally changes.
Change-Id: Iffd3b0b6d8ab1253f5b1bebda88d6f63d5061e19
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/463023
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
If the data was not compressed for whatever reason, it needs to be
copied from the host buffers much in the same way as the patch before
this did.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I5c92db16afbce3ca573c556ee78a51ba6511c564
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/462895
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
If the decompression code path runs into a chunk that wasn't
compressed, the data needs to be copied to the host as the
compression engine was not engaged.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: Ibabd6d6bd2bc5db79953a0a55d7f49d556c08af7
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/462892
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This fixes a segfault found by using a very small logical volume.
The PMEM file chunk map area wasn't including the chunk map struct
itself. In PMEM, a single entry as returned by _reduce_vol_get_chunk_map()
is made up of a 'struct spdk_reduce_chunk_map' plus one uint64_t for
each backing IO unit for the volume (# depends on vol parms). So when
an app got close to the end of the chunk map indices it would run off
the end of PMEM and segfault.
With this fix that no longer happens however data integrity issues now
show up with fio. I believe this fix is valid though and am pursuing the data
integrity issue as something new.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I69a223064c7bbd44bcd0a62d155cf409603970a3
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/461316
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
At the start of time all of values of io_unit_index[] array in
the chunk maps are FF's. When a partial chunk is written, only
some of the io_unit_index[] vals will be assigned values from the
allocated_backing_io_units bit array. When that chunk is written
again, it is not done so in place and at that time in when
_write_write_done() is called, the io_unit_index[] values are
set to FF again and the bit array bits are cleared for the old
chunk so that it is fresh again for use by another write.
This change removes code from an early stage of the write process
where a 'fresh' chuck in allocated. Because of points made earlier,
it is not possible for any of the io_unit_index[] values to be
assigned or have a corresponding bit set in the bit array.
The prev version of this patch cleared the bit array because the
io_unit_index[] array was being cleared however after further
investigation, and for the reasons stated earlier, the io_unit_index[]
did not have a valid value so clearing the bit array was simply wrong.
Removing this dead code clears things up and leaves it to one place
to clear the io_unit_index[], when a chunk is overwritten. Well, 2
places including init time.
Change-Id: I5c4e5360c9c13817d2fa7d3c7d004b44537af7f4
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/458520
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Eliminates need for memset on parts of our scratch buffer
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I00b7213d3c15562ceeda4d7a3ac2bb7cfd41bf66
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/460010
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
spdk_dma_*malloc() is about to be deprecated.
Change-Id: I140e10b2fd07efb48e664cfa00e1d60f604abd21
Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449797
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
In the memcpy elimination patches, the same bug exists in 3
places. When building req->decomp_iov using the host buffers,
req->decomp_iovcnt was being incremented in the loop and also
being used as part of the index messing everything up.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I485ac32502801c1e11b8392b2df7eba06b4f5a9b
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/461053
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
The first optimization to eliminate memcpy was too aggressive and
did so for the read-modify-write operation as well. This didn't
affect the fio tests used that the time but bdevio catches it
right away. When over writing a chunk with data, we first need
to read the old data before applying the new. This patch uses
the scratch buffer for old data as sending it to the user buffer
results in it not being written at the end of the read-modify-write.
There is at least one more bug fix coming after this also found
with bdevio but passed with fio
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I8fe074056434bb4757c68077e2df446861edfd94
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/461032
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This is the first in a series of patches to eliminate memcpy ops
in the comp/decomp paths. Currently the lib uses 2 scratch buffers
and copies all data in and out of them to the user buffers following
a comp/decomp. This patch replaces the memcpy in one of the paths by
constructing an iovec array that points to a combination of the
scratch buffer and user buffer so that user data decompresses
directly into the user buffer and any data in the chunk that isn't
needed by the user will be sent to the scratch buffer.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: Ib1956875729a82d218527bc81795f750d1df2b89
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/459662
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
When setting the offset into pmem for the chunk mamps, the wrong
value was used for the length of the logical map resulting in
map corruption after extended fio run.
Fixes issue #813
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: Icb51cf8f38a04f05f69595ebd510ced7f1b608f3
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/457818
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Prints key info about a volume and its PMEM. As the metadata is
mapped, there's no real reason to dump all this to a file, it
can be accessed via gdb using the addresses printed out.
Signed-off-by: paul luse <paul.e.luse@intel.com>
Change-Id: I2c7b8c32b6142ba0fded623a660b4d7d0c5b19bc
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/458117
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
When we decompress, pass the size of the compressed
data - not the size of the buffer itself.
We also need to remove an assert that's no longer
true since we can now handle compressed chunks.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Ifb7896db12ccbefdd49815b5037af11ddd82e625
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449513
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Most typically, the error will be -ENOSPC, meaning the
destination buffer wasn't big enough to hold the compressed
data. But even for other types of errors, just write the
uncompressed data rather than treating it as an I/O
failure.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Id6526cab95488a1a587b183237f9980c83287761
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449511
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Stupid bug - a chunk is compressed when the number
of io_units for the compressed data does *not* equal
the number of io_units per chunk.
Paul found this during some of his initial DPDK
framework integration testing. I have some better
unit tests coming up to test this further, but want
to get this obvious fix in for now.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Iaf9c78a1c1d6045070e7625c6a54ab3d227c8ea7
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449498
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
When a chunk cannot be compressed enough to save one I/O
unit, we will just write the uncompressed data to disk. In
this case, we want the helper routine to use the decomp_buf
instead of the comp_buf.
To facilitate that, save some information in the request
object on the number of io_units to be read from or written
to disk, and whether the data is compressed or not. We
could easily deduce if the data is compressed based on the
number of io_units but saving it in the structure will
save a few instructions and simplify the code a bit.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I1537130577943e19fe4dfcee58eac453eca3c29b
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449259
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
The unit tests don't really try to compress anything
yet, but this at least gets the pipeline in place.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Ic413850b30e4d9631f3ece2bab40d9026225e5b2
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449097
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
There are a sequence of operations needed for both
read and write I/O. For example, on a write I/O,
we may need to do a read, modify the chunk, then
write the data back to disk.
For read I/O, the name of the callback is
_read_read_done - the first "read" indicates the
I/O type, the second "read" indicates the disk read
part of the sequence.
The write I/O steps aren't using this same naming
convention, so change that here. This will be
important in upcoming patches where we'll be adding
compress/decompress steps into the I/O pipeline -
having a consistent naming strategy will make the code
easier to follow.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Icd525874918378118d807acdbe5dd42d5be03126
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449258
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
This preps for some future changes.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I380258938e2412062b43c3d460a7322c5afdf819
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449096
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
We will actually use these in future patches.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I730ef90da6d93922dd17a5ac16594e66132a5f11
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449086
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
We will need separate temporary buffers for compress/decompress.
A single temporary buffer won't do because a user's read/write
operations may not cover a full chunk - so we'll need one buffer
to read/write the compressed data, and another buffer for
the uncompressed data.
So for now, just prepend rw to the existing fields - this
will signify these fields are used for the read/write operations
to the backing storage device. We'll add additional ones in future
patches for the buffers that will hold the uncompressed data.
Note: the vol->buf_mem and ->buf_iov_mem are not prepending "rw"
because they will be used for the compress/decompress temporary
buffers as well. We'll just double the size of these buffers
when allocating them for the volume.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I7df56ab72769f4689f3abac3354446e9cf78d423
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449085
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
This matches better with the existing buf_iov_mem.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I3b85708672553c281666becc8eaf9f9028da8782
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449084
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Upcoming patches will try to compress the data before
writing it to backing I/O units, and we'll need to save
the exact number of compressed bytes.
For now, since we're not actually compressing data yet,
just save the uncompressed data size to this field. There
will be cases when we cannot realize any compression
savings and will just store the uncompressed data, so
handling this now is one less path we'll need to add later.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I499a89590349e4816fe0fef77cc1bfabde6871bf
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449078
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Previously we were just passing around uint64_t pointers,
since the chunk map was literally only an array of uint64_t.
But we need to store the compressed data size in the chunk
as well. Before adding the compressed data size, let's do
the prep work here to just create the chunk map structure
which for now only includes an array of uint64_t.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Icbfa6e509463d4f560444d3db8acd9e87917835f
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/449076
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Write operations are not in-place, meaning that once it
is completed, it's chunk and backing io units are freed.
Reads in progress to these backing io units, from other
I/O to the same chunk, could cause data corruption.
Simultaneous writes to the same chunk can cause similar
issues.
There are cases where we can relax this in the future -
for example, overlapped reads to the same chunk poses
no problems. We'll leave that as a future exercise.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I3a4d9e8e3ab920f823084cd1bae91f179a4386ff
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/448333
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Upcoming changes will require queuing an I/O if it overlaps
with another I/O to the same logical chunk. So split out
code (especially from the writev path) into separate functions,
so that we can execute an spdk_reduce_vol_request object
whether it's just been created via readv/writev, or after
another I/O to the same chunk has been completed.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I2a216c92e4999313ecc9f7cf157dccd65c9bb30f
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/448332
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
This will help optimize some upcoming patches which
guard against overlapped I/O to the same chunk in the logical
map.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Ia1370fffd3bf3d55dc9ce88a993ed157ecee272a
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/448331
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Discovered in bdev compression test. Vol load was using the index
of the logical map to set the allocated chunk map bits as well as
retrieve the chunk. Exposed with overwrite situations. Also clarrified
one var name that I missed in previous patch.
Also added UT that fails without the fix, passes with the fix.
Change-Id: I776a5af9364cc3d4e8b7dafec22acf23bd463630
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/447969
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Changed a few cases where var name chunk was used where a better
name would be logical_map_index to avoid confusion with 'chunk'
used as a data pointer.
Change-Id: Ib82a783725cad4609c31bfa8997debb3e71e75b9
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/447962
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
_allocate_bit_arrays() needs vol->backing_dev set which was being done
after the call.
Change-Id: Ic8c36c98aee94fbd8230273638011b948cd95675
Signed-off-by: paul luse <paul.e.luse@intel.com>
Reviewed-on: https://review.gerrithub.io/c/443048
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Let the application figure out how to close the
underlying block device after an init fails or
an initialized/loaded volume is closed/destroyed.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Id0b9b99c85ed13166ec9a229eaaa0b0eb04289fd
Reviewed-on: https://review.gerrithub.io/c/440573
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
This will remove the metadata from the associated backing
device and delete the pm_file associated with the reduce
volume.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I30ffd68e5ba69b31ee1be85418c5b8c592d82e70
Reviewed-on: https://review.gerrithub.io/c/437995
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
This requires fixing up the unit test pmem emulation
code - we need to copy the 'persistent' buffer into
the newly 'mmaped' buffer in the pmem_map_file stub.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I4e474f437922e652a57d0b45b6ef92fc713eb587
Reviewed-on: https://review.gerrithub.io/c/437888
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
If _allocate_vol_requests() failed, the caller will call
_init_load_cleanup() to free memory that _allocate_vol_requests()
already freed, and cause segment fault. Setting pointer to NULL keeps
_init_load_cleanup() is safe to free it again.
Change-Id: I9ad09eabf6b65350f174bd5a4faf5ee643cbd23f
Signed-off-by: wuzhouhui <wuzhouhui@kingsoft.com>
Reviewed-on: https://review.gerrithub.io/437292
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
