Issues Fixed in Lightbits 3.9.1

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.
36282	When running the getHost API through REST, in certain cases getHost might produce 'not found', even if the host does exist. It is recommended to use the listHosts API with the hostNQN filter to get the proper results. Two initiators connecting with the same hostNQN are overriding each other in listHosts, showing only one of them. Renaming hostNQN requires 'rm /etc/discovery-client/internal/internal.json'
33173	data-layer: under rare conditions, deleting snapshots could lead to rebuilds not starting and volumes being stuck in degraded/read-only protection states. This issue is fixed in 3.9.1 and 3.8.3 and upgrading is strongly recommended.
32950	node-manager: there is an extremely rare race in the service's startup flow, that combined with a very rare chain of migrations of the same volume, may in theory lead to incomplete rebuilds. This issue is fixed in 3.9.1 and 3.8.3 and upgrading is strongly recommended.
18771	When a Lightbits node is considered to be in a "permanent failure", Lightbits considers the cluster to be smaller. This will affect the minimum allowed replica count for new volumes. For example, in a three-nodes cluster, users will not be able to create a three-replica volume when one of the nodes is considered as a "permanent failure".

Last updated on

Was this page helpful?