On Wed, Aug 14, 2024 at 03:46:45PM +0100, debian-u...@howorth.org.uk wrote:
Off-topic really, but could you explain (or point to an explanation) how applications could be redesigned for this 'new paradigm'. I ask because I used reiserfs because of (a) journalling and (b) handling many small files. I've never seen anything before that suggested I should redesign my applications.
The short answer is that the reason it handles small files well is because Reiser wanted the filesystem to be used for direct storage of small objects, whereas most applications dealing with small objects combine them into a larger object which is what is stored in the filesystem. E.g., a database like sqlite stores records in a large file which the database software manages internally rather than storing each record as a separate file. If the database wanted to take advantage of this paradigm and store small records in individual files, it would exhibit ridiculously poor performance on every other filesystem and OS, and writing a database only for reiserfs seemed overly limiting. Remember reiserfs was always a research project, and never quite done; reiser4 pushed these concepts further (e.g., added various atomic transaction modes) but never got merged.
The best/most portable answer to the question "how do I store a really large number of really small files" is generally "don't do that thing", and the kind of software that did a lot of that is mostly gone (old school usenet servers were one of the biggest drivers, and before usenet went away they were moving away from the original "each article is a file" model toward aggregated models like cnfs). Maildir is one of the last holdouts, and reiserfs never worked well for that anyway (because of atomicity issues; reiser4 was going to fix that if things had gone as planned, but that's long since ceased to matter). Newer filesystems like ext4 and xfs also handle (sane) amounts of many files per directory much better than reiserfs's contemporaries, making the need for alternatives less pressing.
