Op 20/10/2024 om 22:29 schreef Kent
Overstreet:
Is this idea based on "the user only has 1 FS per device?"On Sun, Oct 20, 2024 at 01:19:42PM -0700, Linus Torvalds wrote:Enough said, and you're just making shit up to make excuses. Also, you might want to start look at latency numbers in addition to throughput. If your journal replay needs an *index* that is 2G in size, you may have other issues.Latency for journal replay? No, journal replay is only something happens at mount after an unclean shutdown. We can afford to take some time there, and journal replay performance hasn't been a concern.Your journal size is insane, and your "artificial cap on performance" had better come with numbers.I'm not going to run custom benchmarks just for a silly argument, sorry. But on a fileserver with 128 GB of ram and a 75 TB filesystem (yes, that's likely a dedicated fileserver), we can quite easily justify a btree node cache of perhaps 10GB, and on random update workloads the journal does need to be that big - otherwise our btree node write size goes down and throughput suffers.
I assume I have this setup (and it probably is, looks like mine).
I have 3 bcachefs filesystems each taking 10% of RAM.
So, I end up with a memory load of 30% dedicated to bcachefs caching.
If I read your argument, you say "I want a large btree node cache,
because that's making the fs more efficient". No doubts about that.
VFS buffering may already save you a lot of lookups you're actually
building the btree node cache for.
Theoretically, there's a large difference about how they work,
but in practice, what files will it lookup mostly?
Probably the few ones you already have in your vfs buffer.
The added value of keeping a large "metadata" cache seems doubtful.
I have my doubts about trading 15G of buffer to 15G of btree node cache:
You lose the opportunity to share those 15G ram between all filesystems.
On the other hand, when you perform many different file lookups,
it will shine with everything it has.
Maybe some tuning parameter could help here?
it will at least limit the "insane" required journal size
Janpieter Sollie
