ivampiresp/Spdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test: add blobfs test plan

Browse Source 
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: I86ae72aac40526ec1ee63d14fa89b9817836e0a2

Reviewed-on: https://review.gerrithub.io/361810
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
This commit is contained in:
Jim Harris 2017-05-17 08:29:10 -07:00 committed by Daniel Verkamp
parent 1424b6a554
commit c33dfd741e
1 changed files with 67 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
test/lib/blobfs/test_plan.md Normal file
View File

@ -0,0 +1,67 @@
# SPDK BlobFS Test Plan
## Current Tests
# Unit tests (asynchronous API)
- Tests BlobFS w/ Blobstore with no dependencies on SPDK bdev layer or event framework.
Uses simple DRAM buffer to simulate a block device - all block operations are immediately
completed so no special event handling is required.
- Current tests include:
- basic fs initialization and unload
- open non-existent file fails if SPDK_BLOBFS_OPEN_CREATE not specified
- open non-existent file creates the file if SPDK_BLOBFS_OPEN_CREATE is specified
- close a file fails if there are still open references
- closing a file with no open references fails
- files can be truncated up and down in length
- three-way rename
- operations for inserting and traversing buffers in a cache tree
- allocating and freeing I/O channels
# Unit tests (synchronous API)
- Tests BlobFS w/ Blobstore with no dependencies on SPDK bdev layer or event framework.
The synchronous API requires a separate thread to handle any asynchronous handoffs such as
I/O to disk.
- basic read/write I/O operations
- appending to a file whose cache has been flushed and evicted
# RocksDB
- Tests BlobFS as the backing store for a RocksDB database. BlobFS uses the SPDK NVMe driver
through the SPDK bdev layer as its block device. Uses RocksDB db_bench utility to drive
the workloads. Each workload (after the initial sequential insert) reloads the database
which validates metadata operations completed correctly in the previous run via the
RocksDB MANIFEST file. RocksDB also runs checksums on key/value blocks read from disk,
verifying data integrity.
- initialize BlobFS filesystem on NVMe SSD
- bulk sequential insert of up to 500M keys (16B key, 1000B value)
- overwrite test - randomly overwrite one of the keys in the database (driving both
flush and compaction traffic)
- readwrite test - one thread randomly overwrites a key in the database, up to 16
threads randomly read a key in the database.
- writesync - same as overwrite, but enables a WAL (write-ahead log)
- randread - up to 16 threads randomly read a key in the database
## Future tests to add
# Unit tests
- Corrupt data in DRAM buffer, and confirm subsequent operations such as BlobFS load or
opening a blob fail as expected (no panics, etc.)
- Test synchronous API with multiple synchronous threads. May be implemented separately
from existing synchronous unit tests to allow for more sophisticated thread
synchronization.
- Add tests for out of capacity (no more space on disk for additional blobs/files)
- Pending addition of BlobFS superblob, verify that BlobFS load fails with missing or
corrupt superblob
- Additional tests to reach 100% unit test coverage
# System/integration tests
- Use fio with BlobFS fuse module for more focused data integrity testing on individual
files.
- Pending directory support (via an SPDK btree module), use BlobFS fuse module to do
things like a Linux kernel compilation. Performance may be poor but this will heavily
stress the mechanics of BlobFS.
- Run RocksDB tests with varying amounts of BlobFS cache