Issues Fixed in Lightbits 3.15.1

IDDescription
37395In some rare racy conditions a server may remain stuck in a deleting state.
37205Incorrect handling of IO errors from NVMe SSDs during abrupt recovery may cause node recovery to fail.
37114

In releases 3.13.1 and 3.14.1, the node-manager could fail to start, causing a Lightbits node to fail to come up. This can occur when the following conditions are all true:

  1. A node is configured such that Lightbits will use zero SSD drives in NUMA 1.
  2. Lightbits is configured to use one or more SSD drives in NUMA 2.
  3. Lightbits is configured to use a single instance across multiple NUMA nodes.
  4. The allowCrossNuma flag is set to false. If the node-manager fails to start due to the above, contact Lightbits Support.
36882GFTL service could fail locally due to a rare race condition when a SSD failure/removal, a SSD read submission, and multiple volume rebuilds all occur at exactly the same time.
36722Users can reference the NVMe device by its path name (e.g., /dev/nvme0n1) - as used during the initial system setup - to determine the storage SSD used by servers in the Lightbits storage cluster. However, this could lead to data loss since device names are not persistent across reboots.
36282
  1. 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.
  2. Two initiators connecting with the same hostNQN are overriding each other in listHosts, showing only one of them.
  3. Renaming hostNQN requires 'rm /etc/discovery-client/internal/internal.json'
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard
Next to read:
Known Issues in Lightbits 3.14.1

© 2026 Lightbits Labs™

On This Page
Issues Fixed in Lightbits 3.15.1