All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.