Go to file
Michal Mielewczyk 232f13a8a4 Allow to interrupt cache init, load and stop.
When device used as cache had a big size, it took a lot of time to initialize.
If user would interrupt waiting, asyc OCF init procedure would continue, but
after finish, there was nobody to perfrom kernel part of start nor error
handling.

Now error handling and kernel part of start procedure are moved to completion.
If user will interrupt waiting at any point, newly started cache instance will
be stopped.

Since cache init and load vary only with check for old metadata and initializing
exported objects, they are now merged into one function.

Async cache stop is part of this commit because it was needed for rollback path.

Load, init and stop have common context, because in case of non interrupted
attach CAS needs to wait for rollback to be completed. Common context makes
passing `struct completion` easier between load, init and stop.

This commit is part of patch that will allow to interrupt waiting for OCF
operations.

Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
2020-01-02 18:34:30 -05:00
casadm Typo fix 2019-11-26 16:49:45 +01:00
configure.d configure: Save output from test modules compilation. 2019-10-14 08:43:45 -04:00
modules Allow to interrupt cache init, load and stop. 2020-01-02 18:34:30 -05:00
ocf@3aa68bcb15 Add incremental load tests with core pool 2019-12-20 10:13:25 +01:00
test Merge pull request #230 from Ostrokrzew/init2 2020-01-02 13:03:46 +01:00
utils Fix configuring cache with PP in init script 2019-12-12 10:23:52 +01:00
.gitignore Extending 'configure' script 2019-05-30 06:29:07 -04:00
.gitmodules Move OCL tests from test-framework repository 2019-10-18 15:27:21 +02:00
.pep8speaks.yml Add pep8speaks custom config 2019-07-30 08:42:12 +02:00
configure configure: check for requiured tools. 2019-10-16 03:44:42 -04:00
LICENSE Add LICENSE file 2019-03-29 09:45:21 +01:00
Makefile Initial commit 2019-03-29 08:45:50 +01:00
README.md Update Readme - installation and running tests 2019-10-21 12:48:31 +02:00

Open CAS Linux

Build Status Tests Status Coverity status License

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.

  1. Go to test directory cd test/functional.
  2. Install dependencies with command pip3 install -r test-framework/requirements.txt.
  3. 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 the ip, user and password fields.
    c) For local execution just leave these fields commented.
  4. Run tests using command pytest-3 --dut-config=<CONFIG> where <CONFIG> is path to your config file, for example pytest-3 --dut-config="config/dut_config.yml".

Security

To report a potential security vulnerability please follow the instructions here.