Skip to content

v0.4

Choose a tag to compare

View all tags
@qihui81 qihui81 released this 19 Aug 07:50
· 7 commits to release since this release
v0.4
b5b5bc7
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

Release Notes: v0.4

Among the released assets, you could find:

  • xZTL-v0.4.src.tar.gz - Full source archive, no xNVMe dependencies

Version 0.4

There are several major improvements to the performance of xZTL along with some bugs fixed.

  • A number of zones (the default number is 64) is grouped into a zone group (node)

    Node 0 Node 1 ... Node N
    zone 0 zone 64 ... zone X
    ... ... ... ...
    zone 63 zone 127 ... zone X+63
  • The data placement of SST files of RocksDB has changed. One level SST files of RocksDB are mapped into node (s). When all SST files are deleted of the node, all zones of the node would be reset and reclaimed.
Level # Node #
Level 0 (SST files of level 0, WAL files) Node 0, Node 1, Node 4 ...
...
Level N (SST files of level N) Node 3, Node 2 ...

  • Meta-data is adapted for data recovery

  • It supports various IO paths through xNVMe, e.g. character abstraction of thread pool/io_uring, block abstraction of thread pool/libaio and SPDK

  • RocksDB benchmark.sh is available to benchmark RocksDB performance with xZTL

  • MyRocks (MySQL with RocksDB engine) and [sysbench tool](https://github.com/akopytov/sysbench) is available to run

Known Issues

  • xNVMe backend is hard-coded now, To change the xNVMe backend, we need to change the code in src/ztl-media.c:znd_media_register function first.
  • xZTL-based RocksDB uses hybrid storage, ZNS SSD and conventional SSD. SST and WAL files are stored on ZNS SSD and other files are stored on conventional SSD
Assets 2
Loading