This fixes CAS-on-LVM scenario. Currently how CAS works:
1. LVM instantinates device nodes (not usable at this point)
2. CAS tries to add cores (fails)
3. LVM ends device configuration and issues change uevent
4. We ignore change uevents so we do nothing
This patch makes sure we don't ignore change uevents.
Still, some messages about not being able to open core device
can show up in syslog - there's room for improvement.
Signed-off-by: Jan Musial <jan.musial@intel.com>
Current startup procedure works on an assumption that we will
deal with asynchronously appearing devices in asynchronous way
(udev rules) and synchronous events in the system (systemd units)
won't interfere. If we would break anything (mounts) we would just
take those units and restart them. This tactic was working as long
as resetting systemd units took reasonable time.
As hackish as it sounds it worked in all systems that the software
has been validated on. Unfortunately it stopped working because
of *.mount units taking MUCH longer time to restart even on
mainstream OSes, so it's time to change.
This change implements open-cas systemd service which will wait
synchronously with systemd bootup process for all required Open CAS
devices to start. If they don't we fail the boot process just as
failing mounts would. We also make sure that this process takes place
before any mounts (aside from root FS and other critical FS's) are
even attempted. Now opencas-mount-utility can be discarded.
To override this behaviour on per-core basis you can specify
lazy_startup=true option in opencas.conf.
Signed-off-by: Jan Musial <jan.musial@intel.com>
*opencas.py*: changed result class to contain text values instead of bytes,
translated chache configuring methods to py3,
*init script*: changed regex input on raw string to work in py3.
Signed-off-by: Slawomir_Jankowski <slawomir.jankowski@intel.com>
As "all" target is supported by upper level Makefile, and target
names are passed to subdirectory Makefiles, all of them need to
support "all" target as well. Rename default target for simplicity.
Signed-off-by: Robert Baldyga <robert.baldyga@intel.com>
Write-only (WO) cache mode is similar to Write-back (WB), however
read operations do not promote data to cache. Reads are mostly
serviced by the core device, only dirty sectors are fetched from
the cache.
Write-only cache mode is behaving similarly to Write-back with
respect to flushing dirty data. For example it is required to
explicitly enable/disable flushing when changing cache mode
from WO to something other than WB.
Signed-off-by: Adam Rutkowski <adam.j.rutkowski@intel.com>
