Delta synchronization avoids retransmitting blocks that already exist at the destination. The price is computation. Rsync rolls a weak checksum across possible byte offsets, verifies candidates with a strong digest, and searches the destination’s fingerprint list. Content-defined systems such as dsync find variable-size boundaries and perform a related comparison. Both endpoints can spend more time generating a delta than moving it.
That work is increasingly redundant. BTRFS and ZFS checksum stored blocks. Fs-verity and dm-verity maintain cryptographic digests. Deduplication, object storage, and backup systems also calculate fingerprints for integrity or identity. SkySync asks whether a synchronization protocol can consume those existing results instead of hashing every byte again.
The answer requires more than exposing one checksum field. Storage blocks and synchronization chunks can have different boundaries and algorithms. A filesystem may record CRC32C per block while a protocol expects Adler32 for a larger fixed chunk or SHA-256 for content-defined regions. SkySync therefore treats the storage checksum as an input to a composition algorithm, not as a drop-in protocol token.
Fixed and content-defined deltas need different reuse paths
The fixed-size path, SkySync-F, adapts rsync. Storage metadata supplies checksums for smaller blocks. The client and server combine adjacent values to obtain the checksum of the protocol chunk without reading its payload again. Strong digests confirm candidates, while a revised hash table avoids traversing the original multi-stage weak-checksum structure.
Combining must reproduce the value that direct hashing would produce. For a composable checksum such as CRC, the checksum of concatenated ranges can be derived using polynomial properties and known lengths. Partial blocks at a chunk boundary still need careful handling. SkySync reads or computes the uncovered fragments and combines them with full-block metadata, so the optimized path does not silently change delta identity.
The content-defined path, SkySync-C, adapts dsync. It uses storage checksums to accelerate fingerprint calculation and applies exclusive-or and zero-appending operations to form the weak values required for chunk discovery. A lightweight matching structure narrows candidates before the strong comparison. The server and client collaborate so the side already holding useful metadata performs less payload scanning.
Metadata reuse changes CPU work, not the delta definition
SkySync retains the transmission structures used by rsync and dsync: checksum lists, matching tokens, and changed payloads. It uses 32-bit CRC32C and 256-bit SHA-256 values in the evaluated path. Extra strong-checksum bits make its traffic slightly larger in some cases, but the protocol still sends essentially the same changed regions.
This compatibility matters because an apparent speedup could otherwise come from accepting weaker detection or sending a coarser delta. SkySync’s claim is narrower. The storage system has already paid for fingerprints; algebra and boundary repair turn them into the identifiers the synchronization algorithm needs. The optimization removes repeated work while preserving the file reconstruction result.
Checksum reuse also creates a correctness contract. The metadata must cover the exact file version being synchronized. A write racing with metadata extraction can combine fingerprints from different states. Snapshotting, version identifiers, or filesystem locking must bind payload and checksums to one point in time. An integrity checksum detects corruption only under its own trust model; it is not automatically an authenticated statement from an untrusted remote store.
A WAN testbed separates endpoints from transfer
The evaluation used two Alibaba Cloud instances in separate datacenters. Each had four Intel Xeon 8269CY virtual CPUs, 32GB of memory, and a 1TB cloud SSD rated at 300MB/s. Ubuntu 22.04 and BTRFS ran on Linux 5.15. The path between instances averaged 35ms round-trip latency and 500Mbps; selected tests constrained bandwidth to 100Mbps.
Microbenchmarks modified 10MB and 100MB files using insert, cut, and byte inversion operations. Changes ranged from 256 bytes to 1MB for the smaller file and from 2KB to 8MB for the larger one. Each modification consisted of randomly placed, non-overlapping 256-byte edits. Unmodified files were included because a protocol should ideally prove equality without scanning both payloads again.
Against rsync, SkySync-F accelerated the client by 1.2 to 2.0 times without hardware checksum assistance and reduced client computation by 32.1% to 64.9%. With hardware support, the ranges became 1.1 to 1.8 times and 20.5% to 54.3%. SkySync-C was 1.3 to 1.7 times faster than dsync at the client without assistance, reducing computation by 25.7% to 42.3%.
The server-side maximum was larger because dsync normally calculates fingerprints and searches chunks there. Reusing metadata and simplifying search reduced computation by as much as 89.3%, or 76.5% with hardware checksum acceleration. Hardware narrowed the difference by at most 10.8% in the reported breakdown, but did not remove it because chunk search and boundary work remained.
Network bandwidth determines how much compute savings are visible
Total synchronization includes client work, network transfer, and server work. At 100Mbps, transfers took longer than at 500Mbps, but checksum generation and search still dominated many small-change cases. For changes below 2KB in a 10MB file and below 128KB in a 100MB file, SkySync-F reduced total time by 26.7% to 72.1% without hardware assistance.
As the changed fraction grows, unmatched bytes dominate and every delta scheme approaches a full transfer. No checksum technique can remove that payload. Similarly, on a high-latency low-bandwidth path carrying a large true delta, endpoint CPU savings may be hidden behind network time. The right deployment metric is end-to-end completion at the actual change ratio, not the maximum checksum microbenchmark.
Five real datasets covered chat data, Ubuntu content, Nutanix snapshots, Wikipedia data, and a kernel tree, with one, two, four, and eight threads. SkySync improved completion by about 1.2 to 1.5 times without hardware support and 1.15 to 1.4 times with it. Endpoint portions fell 19.2% to 43.7%. The Ubuntu set was smaller than some others but generated more traffic because its modification ratio was higher, illustrating why file size alone is a poor predictor.
Network traffic remained close to rsync and dsync. SkySync sent slightly more metadata because of its strong checksums, yet it did not exchange saved CPU work for a materially larger delta. That result is essential for inter-cloud use, where egress bytes can cost more than endpoint cycles.
Extraction is cheap only when the storage interface is ready
The researchers extracted SHA-256 metadata from fs-verity on EXT4 and F2FS, built-in SHA-256 or CRC32C from BTRFS, and checksums through custom functions in the MeGA storage system. Across the five datasets, extraction took 1.8 to 119.2 seconds, compared with 26 to 246 seconds for direct checksum calculation under the same conditions.
BTRFS extraction accounted for 0.11% to 7.14% of total SkySync time. EXT4 and F2FS were slower because fs-verity metadata required a more complex extraction process. MeGA was efficient because the authors controlled the metadata layout and retrieval functions. Thus, a storage system having checksums is not enough; it needs a versioned, range-addressable, low-overhead export interface.
Deployments should also account for checksum lifecycle. Metadata may be computed at write time, lazily on first read, or only after sealing a file. Reusing a value shifts cost rather than erasing it if synchronization triggers checksum creation. Operators should attribute checksum CPU and write amplification to the producer as well as the sync job.
The architectural boundary is a shared fingerprint service
SkySync presents file synchronization as a consumer of storage metadata. The same interface could support deduplication, backup comparison, scrubbing, and replication, but shared use increases the need for stable algorithms and explicit provenance. A digest record should identify the algorithm, block length, file version, creation point, and integrity protection.
The strongest fit is a system that already computes checksums, synchronizes large mostly-similar files across expensive links, and can expose metadata consistently. The weakest fit is an unchecksummed store, frequently rewritten small files, or a workload whose deltas are nearly the full object. Encryption and compression can also prevent reuse if fingerprints describe ciphertext or compressed blocks while the sync protocol compares plaintext regions.
The paper’s practical lesson is to audit repeated scans across layers. Storage, backup, replication, and synchronization often calculate related evidence independently. SkySync shows that reusing it can reduce endpoint work by up to 89.3% without changing the network denominator, provided boundaries, versions, and trust are made explicit.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the mechanism, evaluation conditions, results, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2026 presentation page. Copyright remains with the authors, 2026.