Investigate `FileUnpackDest` that uses `fallocate` for unmapped/zeroed areas

Investigate FileUnpackDest that uses fallocate for unmapped/zeroed areas

Summary

When unpacking archives to files (rather than raw block devices), it may be beneficial to use fallocate() to efficiently represent unmapped or zeroed regions as sparse holes rather than explicitly writing zero bytes. This could significantly reduce I/O and storage usage, especially for sparse or partially-zeroed data.

We should investigate whether FileUnpackDest can safely and effectively use fallocate() in these cases.

Goals

• Determine if FileUnpackDest can use fallocate() to punch holes or preallocate sparse regions for unmapped/zeroed chunks
• Improve unpacking performance for large files with sparse data
• Reduce unnecessary writes and disk space usage

Tasks

• Evaluate how FileUnpackDest currently handles zero/unmapped regions
• Investigate use of fallocate() with FALLOC_FL_PUNCH_HOLE and FALLOC_FL_KEEP_SIZE
• Ensure behavior is correct and portable across file systems (e.g., ext4, XFS, btrfs, ZFS)
• Add detection or fallback logic for file systems that do not support hole punching
• Benchmark performance with and without fallocate() on large sparse datasets
• Add tests to verify correctness of sparse restoration
• Document any filesystem-specific behavior or requirements

Considerations

• Only applies to file-based unpack destinations, not raw block devices
• Must ensure that logical offsets and file size remain accurate after hole punching
• Use caution around file systems with compressed or deduplicated backends

Benefits

• Faster unpacking
• Reduced disk writes and wear
• Lower disk usage for sparse or partially empty content