Don't populate cleaning policies during initialization procedure so the user
has to call the latter explicitly.
Until now cleaning policies could be populated in two ways:
- implicitly during cleaning policy initialization,
- explicitly be calling populate.
The difference was that the former was single threaded.
This patch removes the functionally redundant and less efficient code.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
The function not only recovers cleaning policy metadata but is also utilized
to initialize data structures so more generic name is actually more accurate
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
Initializing metadata in an asynchronous manner will allow to use
parallelization utilities in the future commits
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
Normally cleaning policy would be deinitialized during stopping cache which is
one of steps of error handling e.g in case of failed cache activation. But since
`cache_stop()` may be called only for an attached cache instance, cleaning
policy needs to deinitialized explicitly.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
Instead of ignoring `pthread_rwlock_unlock()` return value assert that is must
succeed.
The function returns an error eg. when there is an attempt to unlock the
resource from a different thread than it was originally locked which is illegal
in userspace.
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
- tighten the copyright regex to include all necessary info
- add checking for proper license identifier
- output only in case of error and put it in stderr
Signed-off-by: Rafal Stefanowski <rafal.stefanowski@intel.com>
Besides looking for files with proper extension, check also listed
files without extension, which should contain this header as well.
Signed-off-by: Rafal Stefanowski <rafal.stefanowski@intel.com>
Remove one callback indirection level. I/O never changes it's direction
so there is no point in storing both read and write callbacks for each
request.
Signed-off-by: Robert Baldyga <robert.baldyga@intel.com>
In most (6/9) instances across engines ocf_core_stats_cache_error_update
is called upon each cache volume I/O error, possibly multiple times
per a user request in case of multi-cacheline requests. Backfill,
fast and read engine are exceptions, incrementing error stats only
once per user request.
This commit unifies ocf_core_stats_cache_error_update usage so that
in all the engines error statistic is incremented for once for every
error.
Signed-off-by: Adam Rutkowski <adam.j.rutkowski@intel.com>
It is wastefull to allocate a full 1B to store 1 bit of
alock status per cacheline. Fixed allocation of 128 bits
seems more reasonable.
Signed-off-by: Adam Rutkowski <adam.j.rutkowski@intel.com>
1. On 1 bit per cacheline is required for the status
2. ... however the size must be 8B aligned
Signed-off-by: Adam Rutkowski <adam.j.rutkowski@intel.com>
Make Volumes usable by both pyocf and OCF with clear open/_open split
and clean-up of instance/uuid tracking on C interface only.
Signed-off-by: Jan Musial <jan.musial@intel.com>
We need a strong reference to volume for as long as OCF has it open.
For that I changed instance tracking dictionary from weakvalue to
normal. This way I made sure that GC won't clean up Volume before its
closed.
Signed-off-by: Jan Musial <jan.musial@intel.com>
