Known Issues in Lightbits 3.15.3

ID	Description
41873	Under a specific race condition, if a snapshot is created while a node is down and then deleted during the node’s startup at a very precise timing, the node could become unavailable.
41466	Creating a snapshot with a retention time that exceeds 192 years will fail, and cause a restart of the api-service.
41095	The NodeRebuildNotPossible alert is not triggered as expected.
40883	In the specific case of using VCP to upgrade a cluster, the upgrade to Lightbits version 3.17.1 or higher will fail because VCP cannot parse the new version format. To successfully upgrade the cluster, use the Lightbits core CLI or REST API directly.
40068	In rare cases, a newly-created volume could be assigned the same NSID as an existing volume. This condition can lead to incorrect delete or update operations for volumes sharing the same NSID. If this issue is encountered, contact Lightbits Support for a manual remediation procedure to identify and fix the affected volumes.
37830	In a very rare case, a node may fail to recover and return to an active state if an I/O error or bad block is encountered on an underlying SSD during its startup sequence. This issue prevents a key service (gftl) from initializing correctly and may require manual intervention, such as the removal of the failed SSD from the system, to allow the node to successfully complete its recovery.
37505	In a rare combination of events, the 'physicalOwnedCapacity' volume statistic may report an incorrect value if data at a specific LBA is overwritten with content that has a different compression ratio. In this scenario, the updated length of the overwritten data is not correctly accounted for in the statistic.
33865	In certain cases when migrating volumes during dynamic rebalancing, a VolumeInDegradedProtectionState event could be sent out when the volume is actually fully protected.
28027	A server upgrade status will not update in the following sequence: A server is upgraded to release x.y.z. The operation fails (i.e., times out); however, binaries on the server are updated to version x.y.z. At a later time, the upgrade is attempted again to version x.y.z (this operation is skipped internally, as binaries have already been updated). The upgrade status will continue to show the failed upgrade operation, even though the last upgrade returned with no error.

Last updated on

Was this page helpful?