As a moderator on the reigning most popular long term server of Minetest (held its own for several years, though many players on other servers despise the type of persons they see on it for some reason), on reports from other staff, and the realization that banned players keep coming back to the game and causing issues, I realized that the database can only hold so many ban entries/information before it resets itself, and those freshly banned or very troublesome players come back to the game before they've calmed down.
To combat this space issue, there are a variety of methods you can use.
One is compression, using the functions built into the Minetest LuaJIT 5.1 beta 3 addon subsystem, or the C++ engine for mapblock/chunk compression (not the acclaimed pglz, agiannis, LZ77, K5, ZPAQ, or a trained Zstd algorithm like how Facebook and other data aggrigators use unfortunately).
Another is increasing the database size, or splitting it up into separate parts that each are capable of holding more total or specific storage, for example the bans would stick around, but the ban reasons would fill up and overwrite the first entries or reset instead of releasing all those players back into the game.
And I'm sure there are lots of other methods that can be used to make this ubiquitously used mod better, but I'm no expert.
I'm genuinely surprised xban2 doesn't use a SQLite database. It would prevent this issue where a large xban database hits against Lua's constant limit due to how the database is one large Lua table that gets serialised and deserialised. It'd probably make it faster too since you can run SQL queries against the data and don't have to load it all into memory first.
its a well known issue amongst modders/server owners that using minetest.serialize(1) causes data loss at scale, and to resolve this, you use minetest json handler, as travelnet(2), areas have done(3). this was brought up in an issue on xban2 repo(4), can smalljoker/krock closed it from a pr that helped allievate the issue(5), but not fix it and continues act like its not an issue rather than fix it or reopen the issue - despite being the one to approve the fix in areas....
As a moderator on the reigning most popular long term server of Minetest (held its own for several years, though many players on other servers despise the type of persons they see on it for some reason), on reports from other staff, and the realization that banned players keep coming back to the game and causing issues, I realized that the database can only hold so many ban entries/information before it resets itself, and those freshly banned or very troublesome players come back to the game before they've calmed down.
To combat this space issue, there are a variety of methods you can use.
One is compression, using the functions built into the Minetest LuaJIT 5.1 beta 3 addon subsystem, or the C++ engine for mapblock/chunk compression (not the acclaimed pglz, agiannis, LZ77, K5, ZPAQ, or a trained Zstd algorithm like how Facebook and other data aggrigators use unfortunately).
Another is increasing the database size, or splitting it up into separate parts that each are capable of holding more total or specific storage, for example the bans would stick around, but the ban reasons would fill up and overwrite the first entries or reset instead of releasing all those players back into the game.
And I'm sure there are lots of other methods that can be used to make this ubiquitously used mod better, but I'm no expert.
I'm genuinely surprised xban2 doesn't use a SQLite database. It would prevent this issue where a large xban database hits against Lua's constant limit due to how the database is one large Lua table that gets serialised and deserialised. It'd probably make it faster too since you can run SQL queries against the data and don't have to load it all into memory first.
its a well known issue amongst modders/server owners that using minetest.serialize(1) causes data loss at scale, and to resolve this, you use minetest json handler, as travelnet(2), areas have done(3). this was brought up in an issue on xban2 repo(4), can smalljoker/krock closed it from a pr that helped allievate the issue(5), but not fix it and continues act like its not an issue rather than fix it or reopen the issue - despite being the one to approve the fix in areas....