On Sun, Oct 20, 2024 at 10:51:10PM +0100, Joshua Ashton wrote: > > > On 10/20/24 9:29 PM, Kent Overstreet wrote: > > On Sun, Oct 20, 2024 at 01:19:42PM -0700, Linus Torvalds wrote: > > > On Sun, 20 Oct 2024 at 13:10, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > > > > > And the INT_MAX check wouldn't catch truncation anyways - it'd only > > > > catch integer _underflow_, but allocation size calculations pretty much > > > > as a rule never use subtractions, so I don't think this check was ever > > > > worth much to begin with. > > > > > > It fixed a real security issue. > > > > Which you quite conveniently aren't naming. > > > > > 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. > > Then why are you arguing about there being an "artificial cap on > performance", if you can "afford to take some time there"? > > Am I missing something? The journal keys has to exist as a flat sorted array, and it has to contain _all_ the (sorted, deduped) keys that were in the journal.
