diff options
author | Javier González <jg@lightnvm.io> | 2017-06-30 17:56:42 +0200 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2017-06-30 11:08:18 -0600 |
commit | 076984669db8476c3c9a9f6d0c59a8e2c7e0092f (patch) | |
tree | 390b5fc24a3911f43b7dffec622786c27c5ee292 /drivers/ide/ali14xx.c | |
parent | b5e063a2861a3af00fe3770e5fb85f936facbf42 (diff) | |
download | blackbird-obmc-linux-076984669db8476c3c9a9f6d0c59a8e2c7e0092f.tar.gz blackbird-obmc-linux-076984669db8476c3c9a9f6d0c59a8e2c7e0092f.zip |
lightnvm: pblk: verify that cache read is still valid
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 <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/ide/ali14xx.c')
0 files changed, 0 insertions, 0 deletions