Issues Fixed in Lightbits 3.9.6

ID	Description
41068	A node could crash when powering up from an abrupt failure in the rare case where the volume containing the most recently written data is deleted just before an NVMe device failure - as well as the system completing the full rebuild before any new writes are issued to any volume replicated on that node. If this occurs, the remediation is to either fail the node in place or contact Lightbits Support, who can perform an internal procedure to recover the node from this state.
39628	On Sapphire Rapids machines, the DSA offload can be enabled - causing a Machine Check Exception (MCE) and forcing a reboot. For this to happen, the number of DSA devices on a numa node should be sufficient to allocate the number of channels equal to the size of the duroslight process cpuset (each device has eight channels). This can be confirmed from the duroslight log: "dsa_service: failed to get channels" - which indicates that the offload is not enabled; "configurator - Enabling DSA crc32 offload for reads" indicates that the offload is enabled, and there is a risk of an MCE or other malfunction. In order to prevent the malfunctions in such configurations, the offloads can be disabled in /etc/duroslight/conf.yaml under "configurator" by adding "dsa_ read_crc32: false" and "dsa_write_crc32: false".
37831	In some cases, silent data corruption on an SSD could cause a node crash instead of attempting to recover the data and reporting an event. This can occur if the SSD returns invalid data rather than an I/O error.
36478	Exceeding the max limit of file descriptors (client connections) of 65536 would lead the Duroslight service to fail.
17329	Lightbits exposes latency information per request size. The time window for latency measurement is not synchronized with the measurement of nr read/write requests. Therefore a weighted average calculation of latency over all request sizes will result in inaccurate latency information.

Last updated on

Was this page helpful?