i have a website, uses flat file member system, where as each member has their own folder in a folder called MEMBERS they site now has 32000 members, dot on, and now, new members cant signup is this an OS limitation, whereas you can only have 32,000 directory tree's within 1 folder any help much appreciated Redhat by the way

The filesystem type and kernel version would highly be relevant here. Also, are you sure this is the reason new members cannot sign up? Do you have logs to prove this? Have you manually stepped through the process? Have you checked for quotas on the user process? Also, file stream operations for a VM (PHP, for ex.) can have limitations (possibly in the configuration).

Operating system Linux Kernel version 2.4.25 Machine Type i686 When a user sings up, my php script gets imputted details, and with that makes them a folder, and creates their files which contain email password etc... no more folders r being created, ive even got a php counter that counts a directory for folders, dead on 32,000

I'm pretty sure I know your problem. My guess is you are either running ext2 or ext3. They are very similar. Either way, the original 2.4.x implementations of these fs's has an inode limit of 32000 per directory. The number is set at compile-time (EXT2_LINK_MAX in linux/ext2_fs). I see in the sourcecode this field is specifically checked whenever a new directory is created. There is also at least one other related field which is 16bit (restricting you to 32,768). Redhat patched both these issues some time ago (as far as I know). Either way, I am guessing this is a hardcoded. You might want to try adding new users to a database. Optionally, you can recompile the fs module (if your version is running as a module) or the entire kernel.

yeh as i thought ... Thanx a lot for your help !! if i sort the patch out, is their any other limitations down the line, or will it be unlimted ? roamhosting.net

"if i sort the patch out, is their any other limitations down the line, or will it be unlimted ?" Actually, now I'm not sure about that. I found this LKML post about the patch, but it appears that the offending 16bit limitation was built into a few pieces of 2.4. Therefore the patch mentioned in that message only applies to 2.6. Unless things have been significantly altered, the limitations are still in effect. Browse the thread for more info on solutions. That's all a quick LKML search returned for me. Apparently most users with this specific need migrated to Reiserfs, XFS, or JFS (much better performance for many small files anyway). Ext3 is popular for endusers and migrating legacy systems. There's not a lot of demand for this feature. I would imagine any expanded upper limit would be set to 32bit (i.e. billions). However, looking at the latest 2.6.12 code the 32000 is still in place. The fact it's not even raised to something like 64000 hints to me this issue has been left alone. I'm not sure that anything would go wrong if you recompiled your source version with something like 64000 though, because all the variables I have seen are 16bit. I might do that on a test box (just for kicks), but that's not a great solution. Personally, I would take this time to migrate to a new design or change filesystems. You could get a performance boost from either as well. If you were paying me for this answer, I would probably recommend both.

Thanx Again !! ok well funny enough ive just build a new server thats ready to be shipped off to a data center in america Amd 64bit Athlon 3200+ obviously i have the option to use any file system What file sysem would you recommend which has no 32000 limitation, and uses a flat file system for my one of my websites which recieves 1.5 million hits a day basically their is reading and writing from files every minute and every click that each user makes Cheers ! roamhosting.net