Issues Fixed in Lightbits 3.21.1
ID | Description |
|---|---|
48806 | In v3.20.1, a trim (deallocate) request issued while a volume's replicas were changing. For example, during a node failure, this could be reported to the host as successful even though one replica did not apply it. No data is lost, but the trimmed blocks could remain allocated on that replica, so its contents for those blocks can differ from the other replicas until the blocks are written again. This was fixed in v3.21.1. |
48646 | A false |
48605 | In v3.18.3 and v3.20.1, upgrading a cluster with RPM packages from a release that ships etcd 3.5.18 (for example v3.18.2 or v3.19.1) does not upgrade etcd. The cluster keeps running etcd 3.5.18 instead of the etcd 3.5.30 included in the release. To check a server, run "rpm -q etcd". This is fixed in v3.21.1: upgrading to it also upgrades etcd. |
48532 | node-manager can fail to start if the number of drives present falls below the minimum required for that node's configured layout. For example - after a drive failure, power loss, or planned maintenance. In earlier releases, the node would start with the missing drive marked as failed; affected releases instead failed to start entirely. Workaround: Set |
48205 | When a large number of clone volumes are created from a small number of shared snapshots and a node is then restarted or replaced, some of those clone volumes can become stuck retrying volume creation, which can leave the node's protection groups unable to complete their rebuild. No workaround is currently available. |
48041 | Lightbits management uses state machines that retry operations with an increasing backoff delay until they succeed, to absorb lengthy or racy operations. After a long enough run of consecutive failures of the same operation, the backoff stopped increasing and collapsed to effectively no delay: this was after roughly 1.5 minutes of consecutive retries in the 3.18.x release family, and roughly 16 hours in the 3.19.x and 3.20.x families. The resulting continuous retries could highly load a CPU core and emit a large number of log messages, potentially discarding older diagnostic history needed to investigate the original failure on that node. |
48012 | A stale volume or snapshot could remain on a server and block deletion of the snapshot that it was cloned from. This can happen when a volume or snapshot is created while a server's node-manager service is down (either the service alone, or the whole server powered off), and is deleted exactly as the node-manager is recovering. It applies to the following: a volume that has no snapshots created from it. and a snapshot whose source volume no longer exists and that has no other snapshots created from that volume. If the stale object is a clone - or a snapshot of a clone - deletion of the snapshot it was originally created from never completes. That snapshot stays in Deleting state, also blocking any future operations on the source volume. For example: volume V0 has snapshot S0, and clone C1 is created from S0. If C1 becomes stale, deleting S0 never completes - S0 stays in Deleting state - and no new operation on V0 can start. A stale volume or snapshot could also prevent a rebuild from completing for these volumes/snapshots. Data is not lost, and affected volumes remain accessible and continue to serve I/O. Workaround: Contact Lightbits Support to manually remove the stale volume or snapshot. |
47398 | After a node restarts, the node's reported power-up progress can show 100% before the node has finished powering up, because the value from before the restart is reported. Automation that waits for power-up progress to reach 100% may therefore continue while the node is still recovering. Workaround: Wait for the node to report an Active state instead of relying on power-up progress alone. |
47343 | A race between rebuild with a snapshot deletion could result in |
46869 | If a snapshot is deleted while a rebuild is in progress, the rebuild can fail and log errors similar to "Exceeded maximum number of 50 write attempts". The failed rebuild is not retried automatically, so the affected protection group remains degraded. Workaround: Contact Lightbits Support to restart the node instance on which the rebuild failed. |
46714 | In rare cases, after the etcd service on a server is stopped and restarted, the node on that server may remain inactive and not rejoin the cluster within the expected time. |
46207 | In affected versions, when a server is deployed to listen on any address with IN6ADDR_ANY_INIT, i.e "::" or "[::]", and with explicit IP ACL enforcement enabled, volumes that have a specific IPv4 ACL (rather than ALLOW_ANY) are not visible to hosts, even when the host's IPv4 address is in the ACL. The host connects to the subsystem, but no namespaces are listed. Workaround: deploy the server to listen on a specific address or use INADDR_ANY (0.0.0.0) rather than "::". This issue is fixed in v3.21.1. |
46187 | In affected versions, if one etcd member in the cluster is down, a cluster upgrade can fail to start with the error "Failed to take etcd snapshot: ... context deadline exceeded", depending on which member the pre-upgrade check selects. Workaround: Make sure all etcd members are running before starting a cluster upgrade. This issue is fixed in v3.20.2 and v3.21.1. |
46100 | On clusters that use TPM-based server-side encryption, rotating the cluster root key can fail on servers with slower physical TPM devices. The TPM operations needed for the rotation can take longer than the five-minute default timeout. When this happens, the rotation is rolled back and a |
45998 | VMWare customers may encounter unexpected cluster behavior if/when the client kernel decides to abort NVMe commands issued to the cluster. This can cause unexpected node state fluctuation (down, then back up). |
45912 | If a storage node has some connections to other nodes working but some other connections are stalled or cannot be established, the clients may experience write I/O timeouts until network services on that node are restarted. |
45625 | After running the Ansible cleanup script, stale RAID devices could keep drives attached, causing the next install to detect fewer NVMe drives than expected. Workaround: Stop the mdadm RAID device manually before reinstalling. |
44464 | In affected versions, if the server selected as the new primary for an in-progress volume migration becomes permanently failed, the migration does not abort and instead retries indefinitely, repeatedly updating the cluster state. This issue is fixed in v3.21.1. |
44334 | In affected versions, stopping or restarting the node-manager service on a server (for example during maintenance or an upgrade) could leave the data-path service hung while waiting for a configuration update that never arrives, thus delaying or blocking the server's shutdown. This issue is fixed in v3.18.3 and v3.21.1. |
© 2026 Lightbits Labs™