Note:
The current write cache capability is a beta feature. To apply for beta access, please contact us. Feature Overview
GooseFS write cache is a write acceleration feature of the GooseFS distributed file system. It extends an independent write cache pool on the existing cluster, which consists of all-flash SSD nodes to form a high-performance write layer. Client data is first written to the write cache pool, and then asynchronously persisted to COS by GooseFS background tasks, delivering high throughput and low latency while ensuring data security through multiple mechanisms.
By using write cache, you can obtain the following benefits:
Hot data is written directly to the SSD cache pool, delivering high throughput and low latency.
Data is asynchronously written to COS in a stable manner, smoothing out peaks and valleys to effectively handle sudden upload traffic spikes.
Write throughput scales linearly with the distributed cache, meeting the demands of large-scale concurrent writes.
Working Principle
Note:
Write cache uses an architecture with separate read and write Worker pools. As an additional attribute of a GooseFS cluster, the write cache capability must be enabled independently. The read cache pool (LRU) and the write cache pool (FIFO) run independently without interfering with each other.
The complete write cache process is as follows:
1. The client writes Block data to the write cache Worker, and multiple replicas are supported for writes.
2. The client submits a persistence task to JobMaster and records the file CRC.
3. JobMaster distributes persistence tasks to JobWorker.
4. JobWorker reads data locally, uploads the data and CRC to COS, and COS performs the consistency check.
5. JobWorker reports the task result, including the file CRC.
6. JobMaster confirms the file CRC and updates the persistence status.
Attention:
Before data persistence is complete, unpersisted data remains readable but cannot be evicted.
Data Reliability Assurance
Data reliability in the write cache is ensured through the following mechanisms:
|
Multi-replica disk persistence | Supports configuring one, two, or three replicas. More replicas provide higher reliability. You can choose flexibly based on business requirements. |
End-to-end CRC check | The client calculates the CRC when receiving data and recalculates it when persisting data to COS, ensuring that the CRC of written data is consistent with that of persisted data. |
Raft protocol + DB synchronization | Uses the Raft protocol and DB synchronization to ensure that persistent task information is not lost, allowing persistent tasks to continue even if a node fails. |
The data reliability corresponding to different replica counts is as follows:
|
Single replica | 99% |
Dual replicas (default) | 99.999% |
Three replicas | 99.9999999% (nine 9s) |
Product Specifications
The write cache is sold based on actual physical capacity, and the actual business capacity depends on the number of replicas. For example, if you purchase 30 TB of write cache capacity, the actual cacheable business capacity is 15 TB with 2 replicas and 10 TB with 3 replicas.
Performance Specifications
The write cache has the same specifications as the read cache and provides a throughput of 200 MBps/TB. The reference performance data for QPS and latency is as follows, based on a single-client test scenario:
|
No | 4KB | Nearly a thousand level | > 50ms | Horizontally scalable |
| 1MB | Nearly a thousand level | > 50ms |
|
Yes | 4KB | Nearly ten thousand level | ＜ 10 |
|
Note:
If write cache persistence is disabled, QPS and latency performance will be better than the reference values above.
To further improve performance, contact us for assistance in separating read and write clients to prevent requests from penetrating to COS to check whether files exist. After read and write clients are separated, QPS performance improves by approximately 1.6 times and latency decreases by 40%. Use Limits
To modify the number of replicas, disable the write cache first, reconfigure it, and then enable it again.
Scenarios
COS Upload Burst Peak Shaving
Scenario characteristics: Businesses with bursty upload traffic, including monitoring log uploads, database backup uploads, AutoMQ message queue persistence, RSS data backhaul, AI Agent intermediate result storage, and training intermediate data uploads.
GooseFS write cache solution: Purchase capacity based on throughput requirements, use the write cache pool to provide stable high-throughput writes, and complete data persistence through the asynchronous persistence mechanism to avoid business bottlenecks caused by COS throughput limits.
Temporary Data Storage (No Persistence Required)
Scenario characteristics: Scenarios where upper-layer business data can be recalculated and data persistence is not required, such as temporary writes of training checkpoints.
GooseFS write cache solution: Use a single-replica write cache without enabling persistence to achieve the highest write performance and the lowest storage cost. Meanwhile, thanks to the cache architecture, storage space management is not required. When the GooseFS write cache reaches its capacity limit, earlier written data is evicted through FIFO.
Billing Overview
The pricing of write cache and read cache is the same. The total cluster capacity is the sum of read cache capacity and write cache capacity. For capacity pricing, see GooseFS Pricing Overview. References
To query the path-level persistence status, use the GooseFS command-line tool to run the persistence status query command. Details are as follows: Command Syntax
goosefs fs checkPersist [-R] [-n <N>] <path> ...
Command Parameter Description
|
<path> | Target path. Supports multiple paths and wildcards (same as ls). | Yes |
-R | Recursively traverses subdirectories. If not specified, only direct subfiles + subdirectories are counted (same as ls -R). | No |
-n <N> | Controls the number of unpersisted detail entries displayed. Valid values: positive integer, 0 (print summary only), -1 (display all). | No |
Output Parameter Description
STATE: Indicates the file persistence status. The description of each enum value is as follows:
|
TO_BE_PERSISTED | To be persisted |
PERSISTED | Persisted to UFS |
COUNT: The number of files in this state.
PERCENT: The proportion of files in this state to the total number of files in the <path> directory.
Example
./bin/goosefs fs checkPersist /gz-cos2/1255
CheckPersist: /gz-cos2/1255 (recursive=false, elapsed=0.05s, dirs=0)
STATE COUNT PERCENT
--------------- ---------- -------
TO_BE_PERSISTED 0 0.00%
PERSISTED 1000 100.00%
--------------- ---------- -------
Total 1000 100.00%
All files under /gz-cos2/1255 are persisted.