[crossfire] Forward of moderated message

[Alex Schultz]

crossfire-devel-bounces at lists.sourceforge.net wrote:
>
> ------------------------------------------------------------------------
>
> Subject:
> 32000 file border for player files
> From:
> "Daimonin" <info at daimonin.net>
> Date:
> Sat, 8 Jul 2006 16:34:45 +0200
>
> To:
> "crossfire-devel" <crossfire-devel at lists.sourceforge.net>,
> "daimonin-devel" <daimonin-devel at lists.sourceforge.net>
>
>
> Hello
>
> This bug (or better linux problem) comes from the daimonin server
> but it will effect cf server too.
>
> The last 2 days i encountered strange server downs for the daimonin beta 3
> server. As i investigated, i saw that the server was not able to create 
> a new player dir.
>
> mkdir() failed with the errno EMLINK.
>
> Please read here: http://www.wlug.org.nz/EMLINK
>
> It was as described in the article. We got 32000 player dirs in the
> the data/players directory.
>
> The bad thing: Our server runs a pre-installed Ubuntu 64bit with raid1,
> pre-installed by the provider company. I am pretty sure its not easy,
> not doable without problems and perhaps not possible to change the file
> system.
> For other servers which are perhaps guests on server boxes is a file
> system change impossible too - we have to use what we find there.
>
> In beta 4 we fixed this some month ago by changing the /data/players
> structure like sourceforge manages their user accounts:
>
> we take the first 2 characters of a name, and sort it in a new subfolder
> structure like this..
>
> the name "aab1" and "aab2" will be sorted in this:
>
> data/players/
> a/
> a/aa/
> a/ab/aab1 <- player folder
> a/ab/aab2 <- another player
> a/ac/
> a/ad/
> ..
> ..
> b/
> b/ba/
> b/bb/
> ...
>
> This works very fine and should have a good effect too under files systems
> which scale up with many sub folders (in cpu time).
>
> Of course its not a "100%" fix. In theory, a server can have such many
> players,
> that even a sub folder hit the 32000 folder problem.
>
> Possible fixes then: 
> - use explicit a file system which don't use hard links.
> - change to a DB storing (but there we have performance and
> storing problems perhaps too under different OS?)
>   
Another alternative fix could be doing something such as, for not just
the first two characters having folders, but for each two characters,
having recursive layers of folders. For example, the name "foobar" would
turn to "fo/ob/ar/foobar" and "foobeer" would turn to
"fo/ob/ee/r/foobeer" and "fubar" would turn to "fu/ba/r/fubar". Given
the allowable characters for usernames, that will never exceed 32000
hard links, and at the same time wouldn't require a DB or a filesystem
that doesn't use hard links. That said, I personally think this naming
system might be a little ugly, however it would in theory work so far as
I can tell.

Alex Schultz