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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.