On 2021-10-24 08:18, Carlos E. R. wrote:
My hypothesis is that reiserfs, which sees barely no maintenance, is slow when doing that, specially on rotating rust. In fact, I see the hard disk LED solid "on" while the sync is going on.
It sees no maintenance because, unlike other ill designed s/w and file systems, it don't need it. The big downside of ReiserFS, and why we should be investing in Reiser4FS, is that it is single-threaded. That's a big downer if you have more than one ReiserFS mounted. On the plus side, ReiserFS is true B-tree FS. Ext4 only pretends to be, it still has that crazy UNIX V5/6/7 model of having a separate and predefined 'inode space' and inodes stored on disk as an array. Well OK, BtrFS is also a true B-tree FS, but it is over-ambitious in many respects and is, always has been riddled with problems. And an awkward and difficult to understand set of configurations options (though Ext4/mkfs is worse in that respect). Reiser is a straight forward B-tree FS. It's simple. There's not much you can fiddle with. "It just works". In that, and in it's lack of _need_ for maintenance, it's not a lot of fun. I get to wonder, perhaps I should search for a paper on this, about what happens with B-tree systems (in general) when they get more than half (or X%) full? Is the cost of rebalancing the tree as a result of whatever activity too great? Is that what you are seeing? It's worth considering https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1933172 If you attempt to balance a btrfs filesystem that is nearly full, and this filesystem has had a lot of small, medium and large files created and deleted, such that the b-tree needs to be rotated, when the balance fails due to not having enough free space, the kernel oops, and the btrfs filesystem hangs. Rotating and rebalancing a large (as in nearly full disk) is a fair bit of work, lots of rewriting to disk, demands on free space, hence thrashing to swap. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg