Howdy -- It's been over a year since I posted this patch, with no feedback or activity on the upstream ticket, or here on the list. Is it worth my time to update it to apply to the current release of mkinitcpio? On Thu, Oct 26, 2017 at 3:14 PM Charles Duffy <charles@dyfis.net> wrote:

At present, mkinitcpio outputs are not particularly stable: Generating two consecutive initramfs images from the same inputs can generate archives which are quite entirely unlike each other from the perspective of binary diff tools (rsync, casync, rdiff-backup, xdelta, etc). Making some adjustments to compression and archival can greatly reduce the size of this delta.

A ticket with a proposed patch (adding a --rsyncable option to mkinitcpio) has been opened at https://bugs.archlinux.org/task/56128 -- however, as the advice there has been to consult this mailing list, it may no longer be open as of this writing. :)

The change consists of the following: - Sort the list of files (in the C locale) before passing it to cpio. - When --rsyncable is passed, set all datestamps to the UNIX epoch before generating the cpio archive. - When --rsyncable is passed, pass the --reproducible option to cpio (this creates a dependency on GNU cpio 2.12, prevents device numbers from being included in the archive, and renumbers inode numbers to be consistent when file ordering is unchanged). - When --rsyncable is passed, pass the --rsyncable and --no-name options to gzip (the former tells it to reset the compression table on occasion, sacrificing compression ratio to prevent the effect from changes from cascading throughout too much of the stream; the latter prevents name and timestamp data from being stored in the gzip header itself).

A version of the patch squashing together the two commits already present on the ticket is attached.