[GIT PULL 3/4] fuse2fs: improve block and inode caching

[GIT PULL 3/4] fuse2fs: improve block and inode caching

[Darrick J. Wong]

Hi Ted,

Please pull this branch with changes for ext4.

As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts.  Please let me know if you
encounter any problems.

The following changes since commit 8bf9ced74cb6f7cfc26dfbe0f8fff5ed13f51c90:

debian: update packaging for fuse4fs service (2026-09-11 23:35:02 -0700)

are available in the Git repository at:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git tags/fuse2fs-caching_2026-09-11

for you to fetch changes up to 348aa5ebbb5d52aecba07f6069be986be9bfc4fe:

libext2fs: improve caching for inodes (2026-09-11 23:35:03 -0700)

----------------------------------------------------------------
fuse2fs: improve block and inode caching [v6 3/4]

This series ports the libext2fs inode cache to the new cache.c hashtable
code that was added for fuse4fs unlinked file support and improves on
the UNIX I/O manager's block cache by adding a new I/O manager that does
its own caching.  Now we no longer have statically sized buffer caching
for the two fuse servers.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>

----------------------------------------------------------------
Darrick J. Wong (6):
libsupport: add caching IO manager
iocache: add the actual buffer cache
iocache: bump buffer mru priority every 50 accesses
fuse2fs: enable caching IO manager
fuse2fs: increase inode cache size
libext2fs: improve caching for inodes

lib/ext2fs/ext2fsP.h     |  13 +-
lib/support/cache.h      |   1 +
lib/support/iocache.h    |  17 ++
debugfs/Makefile.in      |   8 +-
e2fsck/Makefile.in       |  12 +-
fuse4fs/Makefile.in      |  10 +-
fuse4fs/fuse4fs.c        |  15 +-
lib/ext2fs/Makefile.in   |  69 ++---
lib/ext2fs/inline_data.c |   4 -
lib/ext2fs/inode.c       | 215 +++++++++++---
lib/ext2fs/io_manager.c  |   3 +
lib/support/Makefile.in  |   6 +-
lib/support/cache.c      |  16 +
lib/support/iocache.c    | 751 +++++++++++++++++++++++++++++++++++++++++++++++
misc/Makefile.in         |  11 +-
misc/fuse2fs.c           |  11 +-
resize/Makefile.in       |  11 +-
tests/fuzz/Makefile.in   |   4 +-
tests/progs/Makefile.in  |   4 +-
19 files changed, 1057 insertions(+), 124 deletions(-)
create mode 100644 lib/support/iocache.h
create mode 100644 lib/support/iocache.c

Re: [GIT PULL 3/4] fuse2fs: improve block and inode caching

[Theodore Tso]

On Fri, Sep 11, 2026 at 11:42:15PM -0500, Darrick J. Wong wrote:
> 
> This series ports the libext2fs inode cache to the new cache.c hashtable
> code that was added for fuse4fs unlinked file support and improves on
> the UNIX I/O manager's block cache by adding a new I/O manager that does
> its own caching.  Now we no longer have statically sized buffer caching
> for the two fuse servers.

The problem is that cache.c is in lib/support, and my long-standing
rule is that the interface of lib/support is not guaranteed to be
stable, and hence libsupport.a is *not* built as a shared library.
For this reason, we can't allow libext2fs to link against
libsupport.a.  If we do, then the interfaces in libsupport.a will leak
into the libext2fs namespace.  This means that applications that link
against libext2fs might accidentally use it.

If we ever change a function in libsupport, and it's also in
libext2fs, then a binary which links against the newer version of the
function in libsupport.a, but then the binary happens to use
libext2fs.so.2 with the older version of that function.... well,
hilarity can ensue.  (Especially with Linux's ELF shared library,
things are OK with AIX shared library and how it handles shared
library linking, but that's another story.)

So there are a couple of ways we can handle this.

1) We could #include cache.c with some kind of #define hack to make
   all of the functions marked to be static.

2). We could move cache.c to lib/ext2fs and rename all of the
functions to something like _libext2fs_cache_xxx (to avoid namespace
collisions), or if we think we are happy publishing it as a public,
stable interface that is used by fuse4fs, we could use
libext2fs_cache_xxx.

What do you think?

						- Ted

Re: [GIT PULL 3/4] fuse2fs: improve block and inode caching

[Darrick J. Wong]

On Tue, Sep 22, 2026 at 10:00:57PM -0400, Theodore Tso wrote:
> On Fri, Sep 11, 2026 at 11:42:15PM -0500, Darrick J. Wong wrote:
> > 
> > This series ports the libext2fs inode cache to the new cache.c hashtable
> > code that was added for fuse4fs unlinked file support and improves on
> > the UNIX I/O manager's block cache by adding a new I/O manager that does
> > its own caching.  Now we no longer have statically sized buffer caching
> > for the two fuse servers.
> 
> The problem is that cache.c is in lib/support, and my long-standing
> rule is that the interface of lib/support is not guaranteed to be
> stable, and hence libsupport.a is *not* built as a shared library.
> For this reason, we can't allow libext2fs to link against
> libsupport.a.  If we do, then the interfaces in libsupport.a will leak
> into the libext2fs namespace.  This means that applications that link
> against libext2fs might accidentally use it.

Ah, right, I forgot that non-static functions can leak out that way.

> If we ever change a function in libsupport, and it's also in
> libext2fs, then a binary which links against the newer version of the
> function in libsupport.a, but then the binary happens to use
> libext2fs.so.2 with the older version of that function.... well,
> hilarity can ensue.  (Especially with Linux's ELF shared library,
> things are OK with AIX shared library and how it handles shared
> library linking, but that's another story.)
> 
> So there are a couple of ways we can handle this.
> 
> 1) We could #include cache.c with some kind of #define hack to make
>    all of the functions marked to be static.

Eww....

> 2). We could move cache.c to lib/ext2fs and rename all of the
> functions to something like _libext2fs_cache_xxx (to avoid namespace
> collisions), or if we think we are happy publishing it as a public,
> stable interface that is used by fuse4fs, we could use
> libext2fs_cache_xxx.
> 
> What do you think?

Hmmm.  I guess it's really up to you as the maintainer.  I was trying to
avoid exporting more things in libext2fs, but we could just move it
there if you're ok with having more API surface.

The funny part would be to export it and then try to convince the
xfsprogs maintainers to make xfsprogs depend on libext2fs to reduce code
duplication <duck>

--D