Skip to content

v0.3.1

Choose a tag to compare

View all tags
@qihui81 qihui81 released this 21 Dec 06:46
· 12 commits to master since this release
v0.3.1
3169358
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.

v0.3.1

Release Notes: v0.3

Among the released assets, you could find:

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

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.

  • Even RocksDB options --target_file_size_base, --write_buffer_size are set, there may exist the error of oversized file especially in multiple threads. The issue will be fixed in the next patch.

Constraints

  • The dependent xNVMe verson is >= v0.0.25 and RocksDB version is >= 6.7

  • To use character devices, the kernel version is >= 5.14

  • Hybrid storage is used to store RocksDB data. sstable files are stored on ZNS SSD and other files are stored on Conventional SSD

  • RocksDB options --target_file_size_base, --write_buffer_size are recommendly set to close less than a zone group size (zone size * zone No.)

Version 0.3

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

  • A number of zones (the default number is 8) is grouped into a zone group (node), and one RocksDB sstable file is mapped to a node, i.e., one RocksDB sstable file is stored on a node uniformly. The zones of the group probably are not used out since the sstable file size does not exceed the node size (zone size * zone No.). When the sstable file is deleted, all zones of the node would be reset and reclaimed.

    Node 0 Node 1 Node 2 Node 3
    zone 0 zone 8 zone 16 zone 24
    ... ... ... ...
    zone 7 zone 15 zone 23 zone 31

  • Mapping table persistence is adjusted for the necessary of data recovery

  • It supports various backends with xNVMe, e.g. character devices of thread pool, character devices of io_uring and SPDK

  • It supports RocksDB sequential read/write, random read/write, overwrite and bulkload. RocksDB benchmark.sh is available to benchmark RocksDB performance with xZTL

  • It can be adopted to MyRocks (MySQL with RocksDB engine) and sysbench tool is available to benchmark MyRocks


# v0.3.1

Release Notes: v0.3

Among the released assets, you could find:

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

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.
  • Even RocksDB options --target_file_size_base, --write_buffer_size are set, there may exist the error of oversized file especially in multiple threads. The issue will be fixed in the next patch.

Constraints

  • The dependent xNVMe verson is >= v0.0.25 and RocksDB version is >= 6.7
  • To use character devices, the kernel version is >= 5.14
  • Hybrid storage is used to store RocksDB data. sstable files are stored on ZNS SSD and other files are stored on Conventional SSD
  • RocksDB options --target_file_size_base, --write_buffer_size are recommendly set to close less than a zone group size (zone size * zone No.)

Version 0.3

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

  • A number of zones (the default number is 8) is grouped into a zone group (node), and one RocksDB sstable file is mapped to a node, i.e., one RocksDB sstable file is stored on a node uniformly. The zones of the group probably are not used out since the sstable file size does not exceed the node size (zone size * zone No.). When the sstable file is deleted, all zones of the node would be reset and reclaimed.

    Node 0 Node 1 Node 2 Node 3
    zone 0 zone 8 zone 16 zone 24
    ... ... ... ...
    zone 7 zone 15 zone 23 zone 31

  • Mapping table persistence is adjusted for the necessary of data recovery

  • It supports various backends with xNVMe, e.g. character devices of thread pool, character devices of io_uring and SPDK

  • It supports RocksDB sequential read/write, random read/write, overwrite and bulkload. RocksDB benchmark.sh is available to benchmark RocksDB performance with xZTL

  • It can be adopted to MyRocks (MySQL with RocksDB engine) and [sysbench tool](https://github.com/akopytov/sysbench) is available to benchmark MyRocks

Assets 2
Loading