Known Issues in Lightbits 3.18.1

44673

In rare cases, performing a KEK rotation while simultaneously executing a high volume of volume/snapshot control plane operations could result in increased etcd contention. This affects only customers utilizing cluster-level encryption with the KEK rotation API.

44435

pmem_init and lbe executables are linked using staticx and therefore require /tmp to be mounted with the exec option enabled; otherwise, these executables will fail to run with "permission denied".

44383

When encryption is enabled, deleting a server that hosts the Active CM could prevent subsequent server additions from completing successfully. To avoid this, stop the CM service on the removed server (or shut down the server) after it has been removed from the cluster.

44298

If a Journal NVMe device fails when the node manager is down, when the node manager comes back up, it can try to take another disk to use for journaling. If the matchers for journaling are the same as for data devices, it can take one of the data devices by mistake - causing the GFTL to crash. For journaling, it is necessary to use specific matchers that are different then the data devices (for example, the serial number).

43456

In a rare combination of conditions, a storage node could fail to start after a restart if placement group membership changed while the node was offline. This requires memory pressure during a prior recovery (causing stale metadata to be persisted), followed by placement group rebalancing that removes volumes from the node. Normal operations and graceful recovery flows are not affected.

42991

A network disconnect that might coincide exactly with a change of state of a NVMe SSD device could prevent correct updates of future changes of this specific NVMe SSD device state (the issue will resolve itself the next time node-manager service is restarted).

42963

When SSD Journaling is enabled, if Duroslight fails due to a non-journal-related issue, the Node Manager (NM) might incorrectly classify the failure as a journal device failure, causing the NM to remain inactive and enter a Permanently Failed state. When SSD Journaling is disabled, a Duroslight failure does not impact the failure scenario. However, users might receive a spurious "journal device failed" event even when journaling is not in use. This is cosmetic only and does not reflect an actual journal issue.

42800

A volume's protections state could fail to update correctly in some cases of network/ETCD unavailability.

42614

Cluster manager and etcd services could suffer a very slow potential memory leak in rare cases. Mishandling of a deprecated GFTL data loss event could cause the event clean logic to stop cleanup of old events, leading to a continuous increase in the number of events stored on the cluster.

42309

In rare cases, a CM failover occurring during the initial KEK rotation process may result in a race condition where the new CM fails to become active, causing some API calls to fail. The data path remains unaffected as long as all nodes are healthy.

41873

Under a specific race condition, if a snapshot is created while a node is down and subsequently deleted during a very precise window in the node's startup sequence, the node may become unavailable.

41466

Creating a snapshot with a retention time greater than 192 years will fail and cause the API service to restart.

41095

The NodeRebuildNotPossible alert may not trigger under conditions where it should, resulting in missed notifications for rebuild-blocking scenarios.

40883

When using VCP to upgrade a cluster to Lightbits 3.17.1 or later, the upgrade will fail as VCP cannot parse the updated version format. To complete the upgrade successfully, use the Lightbits core CLI or REST API directly.

40428

In extremely rare cases, the reported logical size of a volume could be incorrect after a discard operation is performed and TRIM support was enabled.

38706

In some rare cases, Duroslight could hang during shutdown.

38497

When creating a new server to replace another server in the cluster using the --extend-cluster=false flag (which is the default setting), and at a much later time this server and its node experience a permanent failure and fail in place is enabled (causing the servers resources to be migrated), if the server goes active again it might not participate in all proper distribution of replicas over the cluster and could cause an imbalance of resources.

37830

In extremely rare cases, a node may not recover to an active state if an I/O error or bad block is encountered on an underlying SSD during its startup sequence. This prevents a key service (gftl) from initializing correctly and may require manual intervention (such as removing the failed SSD from the system) to allow the node to complete its recovery successfully.

37505

In a rare combination of events, the 'physicalOwnedCapacity' volume statistic may report an incorrect value when 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 reflected 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

In specific circumstances, the server upgrade status may not reflect the correct state after a successful retry. This occurs in the following sequence: 1. A server is upgraded to version x.y.z. 2. The operation fails (for example, due to a timeout); however, the server binaries are successfully updated to version x.y.z. 3. The upgrade is retried to version x.y.z — this step is skipped internally, as the binaries are already up to date. 4. The upgrade status continues to show the previous failed operation, even though the retry completed without error.