The cleaning metadata has been deinitialized in the previous pipeline
step together with other services
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Unfreezing a refcnt might be a sleeping operation so it can't be called
from completion context. Moving D2C refcnt unfreeze to a separate step
in pipeline ensures that it will always be called from process context
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Increasing the occupancy before the backfill request has completed leads
to incorrect statistics
test_lazy_engine_errors() detected the bug in the following scenario:
1. Rio submitted a read request
2. The read turned out to be a full miss. After a successful read from
the core device, engine_read set the metadata bits to valid and
submitted a backfill request
3. In meantime, Rio submitted a write request to the same cache lines
4. Since the test uses an error device as cache (all sectors are
erroneous) the backfill request failed and was redirected to
engine_invalidate
5. engine_invalidate reset the metadata bits to invalid, but since cache
lines had waiters registered, the occupancy wasn't decremented as
there was an assumption that the new owner (in this case, the write
request) would do the bookkeeping
6. Upon receiving cache line locks, the write request detected that
the mapping changed so it was completed with an error without
decrementing the occupancy
7. The incorrect value of cached cache lines was persisted for the whole
lifetime of the cache
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The cleaning metadata has been deinitialized in the previous pipeline step
together with other services
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Flushing metadata has nothing to do with dinitializing services so it
should be a separate step in the stop pipeline
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Move flushing metadata outside cache_detinit_services(), so the function
can be shared between stop() and detach() without redundant ifs.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The completion callback is called only in the cache stop scenario, after
flushing the metadata
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
This resets count_pages_variable on cache-detach, so during the following
cache-attach metadata size is calculated properly.
Signed-off-by: Daniel Madej <daniel.madej@huawei.com>
During core remove/detach ocf_cleaner_refcnt_freeze was called only
when cache was attached, but ocf_cleaner_refcnt_unfreeze was called
regardless of cache state.
Signed-off-by: Daniel Madej <daniel.madej@huawei.com>
After attaching new cache device handle all the IOs in Pass-Through mode
until all the d2c requests are completed.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
The flag isn't reset before retraversation so it might be true even if cache
line was reparted in the meantime
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
Resetting cache_error/core_error in ocf_req_forward_* functions may lead
to overwriting already reported error if the forward is being done in the
loop.
To avoid this potential problem, introduce set of forward init functions
intended to be called before the entire forward operation, which resets
the error code and sets a forward callback.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
We skip cleaning the mapping and moving the cache line to the free list
in a situation when there are waiters on the cache line lock.
Refrain from decrementing core stats in that situation as well, and let
repart of the waiter request do the updates as needed.
Signed-off-by: Robert Baldyga <robert.baldyga@huawei.com>
New caches are added to the list at the point where they are already
initialized and no errors are possible at this point, hence list_del() in error
handling is redundant.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
The fewer (atomic variable accesses on IO path) the better fare
Signed-off-by: Roel Apfelbaum <roel.apfelbaum@huawei.com>
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
