linux-kernel - Re: [GIT PULL] bcachefs changes for 6.12-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240925-aufdrehen-zuzug-43c74793e4bf@brauner>
Date: Wed, 25 Sep 2024 13:41:42 +0200
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Chinner <david@...morbit.com>, 
	Kent Overstreet <kent.overstreet@...ux.dev>, linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Dave Chinner <dchinner@...hat.com>
Subject: Re: [GIT PULL] bcachefs changes for 6.12-rc1

On Tue, Sep 24, 2024 at 06:45:55PM GMT, Linus Torvalds wrote:
> On Tue, 24 Sept 2024 at 17:17, Dave Chinner <david@...morbit.com> wrote:
> >
> > FWIW, I think all this "how do we cache inodes better" discussion is
> > somehwat glossing over a more important question we need to think
> > about first: do we even need a fully fledged inode cache anymore?
> 
> I'd be more than happy to try. I have to admit that it's largely my
> mental picture (ie "inode caches don't really matter"), and why I was
> surprised that the inode locks even show up on benchmarks.
> 
> If we just always drop inodes when the refcount goes to zero and never
> have any cached inodes outside of other references, I think most of
> the reasons for the superblock inode list just disappear. Most of the
> heavy lifting has long since been moved to the dentry shrinking.
> 
> I'd worry that we have a lot of tuning that depends on the whole inode
> LRU thing (that iirc takes the mapping size etc into account).
> 
> But maybe it would be worth trying to make I_DONTCACHE the default,
> with the aim of removing the independent inode lifetimes entirely...

I would be rather surprised if we didn't see regressions for some
workloads but who knows. If we wanted to test this then one easy way
would be to add a FS_INODE_NOCACHE fs_flag and have inode_init_always()
raise I_DONTCACHE based on that. That way we can experiment with this on
a per-fs basis.