From: Nicolas Schier <nsc@kernel.org>
To: David Disseldorp <ddiss@suse.de>
Cc: linux-kbuild@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-next@vger.kernel.org
Subject: Re: [PATCH v2 7/7] gen_init_cpio: add -a <data_align> as reflink optimization
Date: Mon, 18 Aug 2025 21:23:36 +0200 [thread overview]
Message-ID: <aKN9uMf0HeD1Fgqk@levanger> (raw)
In-Reply-To: <20250814054818.7266-8-ddiss@suse.de>
On Thu, Aug 14, 2025 at 03:18:05PM +1000, David Disseldorp wrote:
> As described in buffer-format.rst, the existing initramfs.c extraction
> logic works fine if the cpio filename field is padded out with trailing
> zeros, with a caveat that the padded namesize can't exceed PATH_MAX.
>
> Add filename zero-padding logic to gen_init_cpio, which can be triggered
> via the new -a <data_align> parameter. Performance and storage
> utilization is improved for Btrfs and XFS workloads, as copy_file_range
> can reflink the entire source file into a filesystem block-size aligned
> destination offset within the cpio archive.
>
> Btrfs benchmarks run on 6.15.8-1-default (Tumbleweed) x86_64 host:
> > truncate --size=2G /tmp/backing.img
> > /sbin/mkfs.btrfs /tmp/backing.img
> ...
> Sector size: 4096 (CPU page size: 4096)
> ...
> > sudo mount /tmp/backing.img mnt
> > sudo chown $USER mnt
> > cd mnt
> mnt> dd if=/dev/urandom of=foo bs=1M count=20 && cat foo >/dev/null
> ...
> mnt> echo "file /foo foo 0755 0 0" > list
> mnt> perf stat -r 10 gen_init_cpio -o unaligned_btrfs list
> ...
> 0.023496 +- 0.000472 seconds time elapsed ( +- 2.01% )
>
> mnt> perf stat -r 10 gen_init_cpio -o aligned_btrfs -a 4096 list
> ...
> 0.0010010 +- 0.0000565 seconds time elapsed ( +- 5.65% )
>
> mnt> /sbin/xfs_io -c "fiemap -v" unaligned_btrfs
> unaligned_btrfs:
> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> 0: [0..40967]: 695040..736007 40968 0x1
> mnt> /sbin/xfs_io -c "fiemap -v" aligned_btrfs
> aligned_btrfs:
> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> 0: [0..7]: 26768..26775 8 0x0
> 1: [8..40967]: 269056..310015 40960 0x2000
> 2: [40968..40975]: 26776..26783 8 0x1
> mnt> /sbin/btrfs fi du unaligned_btrfs aligned_btrfs
> Total Exclusive Set shared Filename
> 20.00MiB 20.00MiB 0.00B unaligned_btrfs
> 20.01MiB 8.00KiB 20.00MiB aligned_btrfs
>
> XFS benchmarks run on same host:
> > sudo umount mnt && rm /tmp/backing.img
> > truncate --size=2G /tmp/backing.img
> > /sbin/mkfs.xfs /tmp/backing.img
> ...
> = reflink=1 ...
> data = bsize=4096 blocks=524288, imaxpct=25
> ...
> > sudo mount /tmp/backing.img mnt
> > sudo chown $USER mnt
> > cd mnt
> mnt> dd if=/dev/urandom of=foo bs=1M count=20 && cat foo >/dev/null
> ...
> mnt> echo "file /foo foo 0755 0 0" > list
> mnt> perf stat -r 10 gen_init_cpio -o unaligned_xfs list
> ...
> 0.011069 +- 0.000469 seconds time elapsed ( +- 4.24% )
>
> mnt> perf stat -r 10 gen_init_cpio -o aligned_xfs -a 4096 list
> ...
> 0.001273 +- 0.000288 seconds time elapsed ( +- 22.60% )
>
> mnt> /sbin/xfs_io -c "fiemap -v" unaligned_xfs
> unaligned_xfs:
> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> 0: [0..40967]: 106176..147143 40968 0x0
> 1: [40968..65023]: 147144..171199 24056 0x801
> mnt> /sbin/xfs_io -c "fiemap -v" aligned_xfs
> aligned_xfs:
> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> 0: [0..7]: 120..127 8 0x0
> 1: [8..40967]: 192..41151 40960 0x2000
> 2: [40968..40975]: 236728..236735 8 0x0
> 3: [40976..106495]: 236736..302255 65520 0x801
>
> The alignment is best-effort; a stderr message is printed if alignment
> can't be achieved due to PATH_MAX overrun, with fallback to non-padded
> filename. This allows it to still be useful for opportunistic alignment,
> e.g. on aarch64 Btrfs with 64K block-size. Alignment failure messages
> provide an indicator that reordering of the cpio-manifest may be
> beneficial.
>
> Archive read performance for reflinked initramfs images may suffer due
> to the effects of fragmentation, particularly on spinning disks. To
> mitigate excessive fragmentation, files with lengths less than
> data_align aren't padded.
>
> Signed-off-by: David Disseldorp <ddiss@suse.de>
> ---
> usr/gen_init_cpio.c | 50 ++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 38 insertions(+), 12 deletions(-)
Thanks! Testing with a massively oversized initramfs (600MB) was fun:
from 2:44 down to 38s.
Questions that pop up in my mind:
Now, how can we make other benefit from this? Might it make sense to
introduce a kconfig variable for initramfs alignment -- even though this
is just a build-time optimisation of few seconds?
Kind regards,
Nicolas
next prev parent reply other threads:[~2025-08-19 15:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 5:17 [PATCH v2 0/7] gen_init_cpio: add copy_file_range / reflink support David Disseldorp
2025-08-14 5:17 ` [PATCH v2 1/7] gen_init_cpio: write to fd instead of stdout stream David Disseldorp
2025-08-18 18:40 ` Nicolas Schier
2025-08-14 5:18 ` [PATCH v2 2/7] gen_init_cpio: support -o <output_path> parameter David Disseldorp
2025-08-18 18:40 ` Nicolas Schier
2025-08-14 5:18 ` [PATCH v2 3/7] gen_init_cpio: attempt copy_file_range for file data David Disseldorp
2025-08-18 18:40 ` Nicolas Schier
2025-08-19 0:20 ` David Disseldorp
2025-08-14 5:18 ` [PATCH v2 4/7] gen_init_cpio: avoid duplicate strlen calls David Disseldorp
2025-08-14 5:18 ` [PATCH v2 5/7] gen_initramfs.sh: use gen_init_cpio -o parameter David Disseldorp
2025-08-18 18:40 ` Nicolas Schier
2025-08-14 5:18 ` [PATCH v2 6/7] docs: initramfs: file data alignment via name padding David Disseldorp
2025-08-14 5:18 ` [PATCH v2 7/7] gen_init_cpio: add -a <data_align> as reflink optimization David Disseldorp
2025-08-18 19:23 ` Nicolas Schier [this message]
2025-08-21 8:10 ` David Disseldorp
2025-08-18 18:40 ` [PATCH v2 0/7] gen_init_cpio: add copy_file_range / reflink support Nicolas Schier
2025-08-18 23:46 ` David Disseldorp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKN9uMf0HeD1Fgqk@levanger \
--to=nsc@kernel.org \
--cc=ddiss@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).