Linux-EROFS Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: linux-erofs@lists.ozlabs.org, xiang@kernel.org,
	 linux-fsdevel@vger.kernel.org, amir73il@gmail.com
Subject: Re: [PATCH] erofs: reuse superblock for file-backed mounts
Date: Thu, 30 Jul 2026 13:57:29 +0100	[thread overview]
Message-ID: <amtJX8aTZT5d_sP3@pedro-suse.lan> (raw)
In-Reply-To: <20260730124120.1501126-1-gscrivan@redhat.com>

On Thu, Jul 30, 2026 at 02:41:20PM +0200, Giuseppe Scrivano wrote:
> When the same file is mounted multiple times (via path or fd), reuse
> the existing superblock instead of creating a new one.  This allows
> multiple mounts of the same image to share in-kernel data structures
> more efficiently.
> 
> The backing file is identified by its inode and fsoffset.  If mount
> options conflict, a separate superblock is created transparently as
> a fallback.
> 
> Tested by mounting a 177M Fedora EROFS image 20 times with full
> traversal:
> 
> ```
> \#!/bin/sh
> IMG=${1:-/root/fedora.erofs}
> N=20
> DIR=$(mktemp -d)
> trap "umount $DIR/m* 2>/dev/null; rm -rf $DIR" EXIT
> 
> sync; echo 3 > /proc/sys/vm/drop_caches
> INODES_BEFORE=$(grep erofs_inode /proc/slabinfo | awk '{print $2}')
> MEM_BEFORE=$(grep ^Slab: /proc/meminfo | awk '{print $2}')
> 
> for i in $(seq 1 $N); do mkdir $DIR/m$i && mount -t erofs "$IMG" $DIR/m$i && find $DIR/m$i > /dev/null; done
> 
> echo "Superblocks: $(grep $DIR /proc/self/mountinfo | awk '{print $3}' | sort -u | wc -l)"
> echo "erofs_inode delta: +$(( $(grep erofs_inode /proc/slabinfo | awk '{print $2}') - INODES_BEFORE ))"
> echo "Slab delta: +$(( $(grep ^Slab: /proc/meminfo | awk '{print $2}') - MEM_BEFORE )) kB"
> ```
> 
> unpatched kernel:
> 
> Superblocks: 20
> erofs_inode delta: +46368
> Slab delta: +39952 kB
> 0.08user 0.82system 0:00.98elapsed 93%CPU (0avgtext+0avgdata 4796maxresident)k
> 19168inputs+10304outputs (24major+16672minor)pagefaults 0swaps
> 
> patched kernel:
> 
> Superblocks: 1
> erofs_inode delta: +2044
> Slab delta: +1088 kB
> 0.07user 0.21system 0:00.31elapsed 91%CPU (0avgtext+0avgdata 4848maxresident)k
> 19024inputs+6784outputs (25major+16810minor)pagefaults 0swaps
> 
> The time difference shows that sharing the superblock also benefits
> the page cache and inode cache, as subsequent mounts of the same image
> avoid re-reading the backing file.  This is particularly useful for
> container hosts running multiple containers from the same base image.

Doesn't this approach break-down as soon as you get to change SB flags (through
e.g mount -o remount)? It will change superblock flags for all of them, right?

(I don't think you can switch off the superblock transparently on a
reconfigure?)


-- 
Pedro


  reply	other threads:[~2026-07-30 12:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 12:41 [PATCH] erofs: reuse superblock for file-backed mounts Giuseppe Scrivano
2026-07-30 12:57 ` Pedro Falcato [this message]
2026-07-30 13:49   ` Giuseppe Scrivano
2026-07-30 16:13     ` Giuseppe Scrivano
2026-07-31 13:12       ` Christian Brauner
2026-07-31 13:19         ` Giuseppe Scrivano
2026-07-31 13:32           ` Christian Brauner

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=amtJX8aTZT5d_sP3@pedro-suse.lan \
    --to=pfalcato@suse.de \
    --cc=amir73il@gmail.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xiang@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