Abstract: A memory leveling system updates physical memory blocks, or blocks, to maintain generally even wear. The system maintains an update count for each block, incrementing a wear level count when the update count reaches a wear level threshold. The system compares a wear level of blocks to determine whether to update a block in place or move data on the block to a less-worn physical block. The system groups the blocks into wear level groups identified by a common wear level to identify blocks that are being worn at a faster or slower than average rate. If an empty block count of a least worn group drops below a threshold, the system moves data from one of the blocks in the least worn group to an empty block in a most worn group.

Abstract: A memory leveling system updates physical memory blocks, or blocks, to maintain generally even wear. The system maintains an update count for each block, incrementing a wear level count when the update count reaches a wear level threshold. The system compares a wear level of blocks to determine whether to update a block in place or move data on the block to a less-worn physical block. The system groups the blocks into wear level groups identified by a common wear level to identify blocks that are being worn at a faster or slower than average rate. If an empty block count of a least worn group drops below a threshold, the system moves data from one of the blocks in the least worn group to an empty block in a most worn group.

Abstract: Multiple competing processors cooperatively manage access to a shared resource. Each processor separately stores a lock table, listing shared resource subparts, such as memory addresses of a data storage device, for example. The lock tables are stored in nonvolatile storage. In each lock table, each subpart is associated with a “state,” such as; LOCAL or REMOTE. In response to access requests from the hosts, the processors exchange various messages to cooperatively elect a single processor to have exclusive access to the subparts involved in the access requests. After one processor is elected, the lock-holding processor configures its lock table to show the identified subpart in the LOCAL state, and all non-lock-holding processors configure their lock tables to show the identified subpart in the REMOTE state. Thus, rather than replicating one lock table for all processors, the processors separately maintain lock tables that are coordinated with each other.

Abstract: Multiple competing processors cooperatively manage access to a shared resource. Each processor separately stores a lock table, listing shared resource subparts, such as memory addresses of a data storage device, for example. The lock tables are stored in nonvolatile storage. In each lock table, each subpart is associated with a “state,” such as LOCAL or REMOTE. In response to access requests from the hosts, the processors exchange various messages to cooperatively elect a single processor to have exclusive access to the subparts involved in the access requests. After one processor is elected, the lock-holding processor configures its lock table to show the identified subpart in the LOCAL state, and all non-lock-holding processors configure their lock tables to show the identified subpart in the REMOTE state. Thus, rather than replicating one lock table for all processors, the processors separately maintain lock tables that are coordinated with each other.

Abstract: To satisfy host requests, two competing processors self-manage access to a shared resource. Each processor maintains a lock table listing that processor's access state regarding the shared resource. Each processor repeatedly sends the other processor a state announcement message representing the processor's state. These include birth cry, heartbeat, or death knell messages. Whenever certain join-entry conditions apply to a processor, the processor performs a JOIN operation to evaluate and attempt to synchronize its lock table with the other processor's lock table. If data is needed from the other processor's lock table, the processor changes its state announcement message to birth cry. If the processor successfully synchronizes its lock table with the other processor, the JOIN operation dictates DUAL mode for that processor. If the synchronization attempt fails, SOLO results. When JOIN completes, the processor operates in its chosen mode.