Skip to content

v0.2.11

Choose a tag to compare

@github-actions github-actions released this 03 Oct 23:14
· 163 commits to main since this release
v0.2.11

Changelog

Added

  • Vendored nlohmann/json (single-header, MIT) for parsing command output in the new storage backends below.
  • New lvm:// storage backend: objects are LVM Logical Volumes, provisioned via lvcreate/lvremove. A new object is fully zeroed before it becomes visible (LVM itself only zeroes the first 4KiB of a new LV), so it never exposes another object's leftover data; any staging LV left behind by a process that crashed mid-create is swept and removed on the next create() against that VG.
  • New zfs:// storage backend: objects are ZFS zvols, provisioned via zfs create/zfs destroy.
  • Consistent startup/connection INFO logging across rawstor-ost, rawstor-vhost, rawstor-vhost-qemu and rawstor-vduse: version at startup, waiting for a connection, client connected, client disconnected.
  • rawio::Queue::timeout_multishot() (and its rawio_timeout_multishot() C API counterpart): the multishot counterpart of timeout(), firing once every given number of microseconds until canceled instead of resolving once.

Changed

  • The packaged rawstor-ost.service systemd unit's backing store is now configurable via a LOCATION environment variable (default file:///var/lib/rawstor, unchanged) instead of being hardcoded in ExecStart — set it in /etc/rawstor-ost.conf, same as the unit's other overridable settings.

Fixed

  • rawstor create/list/remove/show/info against a multi-backend LOCATION/TARGET (comma-separated URIs) could intermittently fail with "No buffer space available": the CLI's internal I/O queue was sized for a single backend at a time.
  • The same "No buffer space available" (ENOBUFS) failure could also surface under a small enough --queue-size (io_uring builds only): the submission ring is now flushed and retried instead of failing outright when it's full of not-yet-submitted entries.
  • Object::flush() could report success (and durability) before a write it was still waiting on had actually completed, if a later write happened to finish first -- affects ost://, where responses are matched by request id and can legitimately arrive out of order.
  • Building with GCC 15.2.0 could hit an internal compiler error in Connection::_with_retry()'s coroutine code.

Contributors

Assets

Source tarball

Debian/Ubuntu packages

RPM packages

Python package