AIX

Something else comes to my mind:
http://www-01.ibm.com/support/knowle...52.htm%23wq169
Have a look! (Increasing size of Data_segment...)

Hi vbe,

I tried this and the problem still remains.

---------- Post updated at 10:37 AM ---------- Previous update was at 10:12 AM ----------

For me a big amount of files can lead to that message (not only in NFS...), the question is what quantity for AIX4.3.3...

Hello again vbe,

I had few questions I was hoping you might be able to help me with:

1) Below are the 3 instructions for increasing the data segments.

Code:

export LDR_CNTRL=MAXDATA=0x10000000 start_process unset LDR_CNTRL

Am I correct that the second instructions "start_process" is not a command to run but instead is actually telling you to work on whatever it is you need the size of the data segments increased for?



2) I ran a test and instead of nfs mounting all of /directoryA to the AIX 4.3.3 machine, I just nfs mounted a subdirectory /directoryA/subdirectory1 to the AIX 4.3.3 machine. I was able to go into the mounted subdirectory1 and could successfully run "ls" and "make". This subdirectory only had a few files in it. This makes me again think that the number of files is the cause of the problem. Are there any other values (environmental variables, etc...) that I might be able to change to allow for "ls" and more importantly "make" to successfully run in a directory with many files in it?

Thanks again for your continued assistance

I've hit this with AIX 5.1 (32-bit) as a client of RHEL 6.3 (64-bit)

It appears that you can play around as much as you like on the 32-bit side, but if the 64-bit server writes a new file when you have more than about 40 files in a directory, then the 32-bit side fails from then on until the number of files is reduced (by the 64-bit side, obviously) and then the client will work happily again.

It was suggested to us that the directory 'file' changes after a certain number of entries when edited on the 64-bit side and that the 32-bit side doesn't understand and goes off in a mad loop until eventually it exhausts memory (set by ulimit) and fails, returning control to the command line.

Our only way around this whilst we still have the need is to split up the files into sub directories such that any one of them has less than the limit of about 40 (for files, count any item, links, directories, pipe files etc.)

It's not great, but that's what we had to do. An alternate was to mount the NFS share the other way round, but that relies on disk space on the other side being available and changing any other clients to pick up the replacement 32-bit server. You could have a 32-bit server just to server NFS to all the others, but they are largely unsupported now.



Sorry it's not great news,
Robin
Liverpool/Blackburn
UK