linux-toradex.git/drivers/lightnvm, branch v4.14-rc7

lightnvm: pblk: advance bio according to lba index

2017-07-28T14:06:00+00:00

When a lba either hits the cache or corresponds to an empty entry in the
L2P table, we need to advance the bio according to the position in which
the lba is located. Otherwise, we will copy data in the wrong page, thus
causing data corruption for the application.

In case of a cache hit, we assumed that bio->bi_iter.bi_idx would
contain the correct index, but this is no necessarily true. Instead, use
the local bio advance counter and iterator. This guarantees that lbas
hitting the cache are copied into the right bv_page.

In case of an empty L2P entry, we omitted to advance the bio. In the
cases when the same I/O also contains a cache hit, data corresponding
to this lba will be copied to the wrong bv_page. Fix this by advancing
the bio as we do in the case of a cache hit.

Fixes: a4bd217b4326 lightnvm: physical block device (pblk) target

Signed-off-by: Javier González 
Signed-off-by: Jens Axboe

lightnvm: pblk: remove unnecessary checks

2017-07-07T19:17:36+00:00

Remove unnecessary checks when freeing dma memory in the completion
path.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: control I/O flow also on tear down

2017-07-07T19:17:34+00:00

When removing a pblk instance, control the write I/O flow to the
controller as we do in the fast path.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: set line bitmap check under debug

2017-06-30T17:08:18+00:00

Do bitmap checks only when debug mode is enable. The line bitmap used
for mapping to physical addresses is fairly large (~512KB) and it is
expensive to do this checks on the fast path.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: verify that cache read is still valid

2017-06-30T17:08:18+00:00

When a read is directed to the cache, we risk that the lba has been
updated during the time we made the L2P table lookup and the time we are
actually reading form the cache. We intentionally not hold the L2P lock
not to block other threads.

While strict ordering is not a guarantee at this level (unless REQ_FLUSH
has been previously issued), we have experience that some databases that
have recently implemented direct I/O support, issue metadata reads very
close to the writes, without issuing a fsync in the middle. An easy way
to support them while they is to make an extra effort and check the L2P
map right before reading the cache.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: add initialization check

2017-06-30T17:08:18+00:00

Add a sanity check to the pblk initialization sequence in order to
ensure that enough LUNs have been allocated to store the line metadata.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: remove target using async. I/Os

2017-06-30T17:08:18+00:00

When removing a pblk instance, pad the current line using asynchronous
I/O. This reduces the removal time from ~1 minute in the worst case to a
couple of seconds.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: use vmalloc for GC data buffer

2017-06-30T17:08:18+00:00

For now, we allocate a per I/O buffer for GC data. Since the potential
size of the buffer is 256KB and GC is not in the fast path, do this
allocation with vmalloc. This puts lets pressure on the memory
allocator at no performance cost.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: use right metadata buffer for recovery

2017-06-30T17:08:18+00:00

Fix bad metadata buffer assignations introduced when refactoring the
medatada write path.

Fixes: dd2a43437337 lightnvm: pblk: sched. metadata on write thread
Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe

lightnvm: pblk: schedule if data is not ready

2017-06-30T17:08:18+00:00

When user threads place data into the write buffer, they reserve space
and do the memory copy out of the lock. As a consequence, when the write
thread starts persisting data, there is a chance that it is not copied
yet. In this case, avoid polling, and schedule before retrying.

Signed-off-by: Javier González 
Signed-off-by: Matias Bjørling 
Signed-off-by: Jens Axboe