aaedfb35dd
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>
Open CAS Linux
Open CAS accelerates Linux applications by caching active (hot) data to a local flash device inside servers. Open CAS implements caching at the server level, utilizing local high-performance flash media as the cache drive media inside the application server as close as possible to the CPU, thus reducing storage latency as much as possible. The Open Cache Acceleration Software installs into the GNU/Linux operating system itself, as a kernel module. The nature of the integration provides a cache solution that is transparent to users and applications, and your existing storage infrastructure. No storage migration effort or application changes are required.
Open CAS is distributed on BSD-3-Clause license (see https://opensource.org/licenses/BSD-3-Clause for full license texts).
Open CAS uses Safe string library (safeclib) that is MIT licensed.
Installation
To download latest Open CAS Linux release run following commands:
wget https://github.com/Open-CAS/open-cas-linux/releases/download/v19.9/open-cas-linux-v19.9.tar.gz
tar -xf open-cas-linux-v19.9.tar.gz
cd open-cas-linux-v19.9
Alternatively, if you want recent development (unstable) version, you can clone GitHub repository:
git clone https://github.com/Open-CAS/open-cas-linux
cd open-cas-linux
git submodule update --init
To configure, build and install Open CAS Linux run following commands:
./configure
make
make install
The ./configure performs check for dependencies, so if some of them are missing,
command will print their names in output. After installing missing dependencies
you need to run ./configure once again - this time it should succeed.
Getting Started
To quickly deploy Open CAS Linux in your system please follow the instructions available here.
Documentation
The complete documentation for Open CAS Linux is available in the Open CAS Linux Administration Guide.
Running Tests
Before running tests make sure you have a platform with at least 2 disks (one for cache and one for core). Be careful as these devices will be most likely overwritten with random data during tests. Tests can be either executed locally or on a remote platform (via ssh) specified in the dut_config.
- Go to test directory
cd test/functional. - Install dependencies with command
pip3 install -r test-framework/requirements.txt. - Create DUT config. See example here.
a) Set disks params. You need at least two disks, of which at least one is an SSD drive.
b) For remote execution uncomment and set theip,userandpasswordfields.
c) For local execution just leave these fields commented. - Run tests using command
pytest-3 --dut-config=<CONFIG>where<CONFIG>is path to your config file, for examplepytest-3 --dut-config="config/dut_config.yml".
Security
To report a potential security vulnerability please follow the instructions here.