You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.