linux-fsdevel.vger.kernel.org archive mirror
 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 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).