Feature Request: Expose 4K block metrics and dirty page counts in summary output

[birdie-github]

Component: CLI / Reporting
Type: Feature Request
Severity: Enhancement

Summary

Add metrics to the end-of-run summary (or under -v/--stats) reporting the total count of distinct 4K storage blocks modified and the estimated unaligned filesystem write volume during the transfer.

Motivation

Current rsync summary statistics report application-level network metrics:

sent 81,484,254 bytes  received 3,616,747 bytes  56,734,000.67 bytes/sec
total size is 573,105,412  speedup is 6.73

While accurate for network accounting, these numbers misrepresent the actual storage impact on modern NVMe and SSD drives:

1. Delta Transfers & In-place Updates: When using --inplace and --no-whole-file, sub-4K delta writes still force the kernel/filesystem (ext4, XFS, Btrfs) to dirty full 4KB filesystem blocks.
2. SSD Write Amplification Factor (WAF): SSD flash memory operates on page (4K–16K) and erase block (1MB–8MB) boundaries. Small, scattered writes cause significant flash translation layer (FTL) garbage collection and wear.
3. Observability Gap: Users attempting to optimize sync jobs for flash longevity currently have no way of knowing whether a 100 KB delta update dirtied 100 KB or 50 MB worth of underlying filesystem blocks.

Proposed Solution / Feature Description

Include block-level metrics in the --stats breakdown (or via a dedicated flag like --block-stats):

• 4K Blocks Dirtied / Touched: Count of unique $4,\text{KiB}$ aligned blocks spanned by written ranges.
• Effective Filesystem Write Payload: The total volume calculated by (dirtied_4k_blocks * 4096).

Example Envisioned Output

Number of files: 1,204
Number of created files: 0
Number of deleted files: 12
Number of regular files transferred: 42
Total file size: 573,105,412 bytes
Total transferred file data: 81,484,254 bytes
Dirtied 4K filesystem blocks: 23,104 (94,633,984 bytes effective)
Literal data written: 81,484,254 bytes
Speedup is 6.73

Implementation Notes & Feasibility

• In-Memory Tracking: During in-place file modification, rsync calculates offset and length pairs for write operations. Rounding these ranges to $4096$-byte boundaries (offset & ~4095 to (offset + length + 4095) & ~4095) allows tracking dirty blocks per file without querying kernel statx/fiemap.
• Zero System Call Overhead: Simple bitwise integer math on the existing write range calculations during local or receiver-side operations avoids adding I/O syscalls.

Use Cases

• Flash Wear Optimization: Helps sysadmins evaluate whether flags like --inplace or file-level pre-allocation actually reduce disk wear for their specific workload.
• Database / Shared Library Syncing: Provides clear feedback when syncing small byte modifications across large binary blobs (e.g., SQLite databases, VM disks, .so libraries).

[steadytao]

Rsync could potentially report an estimate of logical 4KB ranges touched by its own write calls but it cannot accurately report dirty filesystem pages, physical write volume or SSD write amplification. Those depend on uncontrollable factors. The proposed names and wear claims would therefore be misleading. System-level tracing such as eBPF/blktrace is the appropriate source for physical-write analysis, if scoped. Thoughts?

[birdie-github]

Rsync could potentially report an estimate of logical 4KB ranges touched by its own write calls but it cannot accurately report dirty filesystem pages, physical write volume or SSD write amplification. Those depend on uncontrollable factors. The proposed names and wear claims would therefore be misleading. System-level tracing such as eBPF/blktrace is the appropriate source for physical-write analysis, if scoped. Thoughts?

I'm fine with the tool reporting the volume of modified 4K blocks.