When Access receives a volume I/O request, it follows the internal logic of ABS to perform the following steps:
Access requesting volume metadata information from Meta
Only the current Meta Leader can respond to this request; other Meta nodes do not provide metadata services. The Access request includes the Volume ID and VExtent No. VExtent No. is derived from the offset of the current volume's I/O request and represents the data block's extent ID and control attributes (such as whether COW is needed). Since each extent is 256 MiB in size, 0–256 MiB corresponds to the first data block in the volume data block table, with an extent No. of 0; 256 MiB–512 MiB corresponds to the second data block, with an Extent No. of 1, and so on.
If striping is enabled, the mapping method will be slightly different. Assuming a stripe size of 256 KiB and a stripe count of 4, the data is sequentially distributed in 256 KiB stripes across data blocks on different physical disks. For example, 0 to 256 KiB corresponds to Extent No. 0, and 256 KiB to 512 KiB corresponds to Extent No. 1, and so on, as shown below:
Meta returning metadata query results
Meta uses the Volume ID and VExtent No. to query the volume data block table and retrieve the corresponding LExtent information. The query result includes the redundancy policy of the logical data, data information about the cache tier and capacity tier, the addresses of the chunks where the physical data shards are located, and the owner of the LExtent access permissions (a specific Access), among other details. In thin provisioning mode, during the first write operation, Meta allocates physical space for the data block. Access caches metadata information in memory after receiving it, reducing the number of queries to Meta. If the access rights to the corresponding LExtent are not owned by the Access that initiated the request, the current Access forwards the request directly to the rights holder.
Privilege-held Access handling extent I/O
Read request
For read requests, if the data exists in the cache tier, it is read directly from the cache. Otherwise, the data is retrieved from the capacity tier. For frequently accessed data, if the system detects that the cluster is deployed in a tiered storage deployment mode, the system may also promote hot data to the read cache of the cache tier to improve access performance. Read operations require accessing only one set of valid data, without needing to visit all shards.
Write request
The write handling depends on the storage form and volume policy:
Tiered mode with different media: When the load on the cache tier is low, writes first enter the cache tier, and subsequently, inactive data sinks to the capacity tier. When the load on the cache tier is high, write requests that are friendly to the capacity tier (for example, if the capacity tier uses the replication policy and the I/O granularity aligns with the management engine) are directly written to the capacity tier.
Tiered mode with unified media: The I/O of replica volumes is directly written to the capacity tier, while the I/O of EC volumes first writes to the cache tier before sinking to the capacity tier.
For write requests, a success response is returned only when all data shards are written successfully. When a network or storage anomaly causes some shard writes to fail, Access will exclude these shards and initiate data recovery. If a write operation is not completed within a specified period of time, Access terminates the operation and removes the problematic shard, and then triggers the recovery process. If all shard writes fail, a retry operation is triggered. If a read request fails, Access retries reading from other shards, and if all fail, it starts a full retry attempt.
