number of automounts limit

AFAIK the reason for that behaviour is not mountd or nfsd (and not automount at all), but the kernel itself.
Each mount request starts at least one new nfsd process, but the max. number of processes per user is limited in the kernel. 256 per default for users, 256 +24 for root.
You need to recompile your kernel. I don't know exactly where to make the change, search for "define.*TASK" in /usr/include *.h files. MOst like for NT_TASK and MAX_TASK

ahoffmann,

Thanks...can you pls let me know what exactly i have to do.

It will be more thankful if u can help that.



msnr

for kernel 2.2.x, you shoulod at least get  task.h for following:

  find /usr/ -type f -name \*.h -exec grep -l NR_TASK {} \;

change value of NR_TASK, then recompile your kernel.

According to your question, I assume that you use RH, which probably uses kernel 2.4.x. Unfortunately I do not know where NT_TASKS has gone there, AFAIK there is no longer a hardcoded limit, just the amount of memory.

ahoffmann,

Thanks...can you pls let me know what exactly i have to do.

It will be more thankful if u can help that.



msnr

hi..ahoff...

i checked in my /usr  directory...
i couldnt able to find any *.h files....
i have used following command

find . -depth|grep *.h

correct me if iam wrong.

msnr, the wildcard will be expanded in the directory you're "standing" in. Not good;-). Try:
find . -depth|grep ".h$"

Will give you more:-)

-- Glenn

Ooops, missed a backslash:-)
Should have been:
find . -depth|grep "\.h$"

-- Glenn

find /usr -name \*.h

One problem is due to the number of dynamically allocated device nodes. All of these devices have the same major number, which limits the kernel to 256 non-device mounts. [get_unamed_dev()]

An nfs mount requires a device allocation, and is thus subject to this limit. I am surprised that you are getting only circa 150 mounts. Do you have other mounts, such home directories?

One could also argue the effectiveness of such "excessive" nfs mounting. If the objects to be mounted reside on one host, and in a common hierarchy, you should strive to mount a "top node" (perhaps solving dependencies with symlinks). I'm not too familiar with modern ClearCASE, so I really don't know the feasibility of that.

-- Glenn

yes i have other mounts on that machines ..like home directories...


can someone give the solutions finally , what to do.?

As Gns said above, you can mount a directory higher up in the hierarchy, ie. rather than mounting /a/b/c, /a/b/d and /a/b/e separately, just mount /a/b/ instead.

If that's not possible because the directories are spead over a very many machines, then move the data onto fewer machines Doing so will also reduce the number of machines that absolutely must be up and running.

The problem with "lost" mounts was present all the way back in the venerable SunOS4 automounter (daemon solution). I'd guess the same to be true for amd. Automounting is really not that good a solution, but it's there more or less so...:-)

The more mounts the automounter "handles", the more likely that trouble will arise. So please, if possible, follow my/pjb1008s advice on this.

-- Glenn

Im using automounter since the beginning of dawn (SunOS3), and never got such limiting problems (well, never tried more than 255 mounts:). I agree with pjb1008 that the linux automounter (a long with NIS) is one of Linux's bad faces, but it works in simple environments. pjb1008, are you going to fix that ;-)

I do not agree with Gns about the automounter performance (except for some Linux versions).

Back to the topic:
  we identified 2 limits now: #processes per user, and #unamed devices
so it sounds wise to limit the total number of mounts

How about simply setting the timeout for the automounter to for example 30 seconds? This should be sufficient for reading and/or writing files hrough the application.

Every man has his own experiences, mine were thoroughly bad (with respect to SunOS4 automounter). The solution was the one I outlined above.

-- Glenn

[Aside: If you need convincing that Sun can't write an automounter either, cause a directory to be mounted from two processes simultanously. Every so often, you'll find that one process gets the directory that is the mountpoint itself (ie. the directory that is covered by the mounted filesystem).]

Anyway, setting the expiry time to 30 seconds is increasing the number of opportunities for the races in the automount IPC mechanism to occur. Proceed with caution.

A comment from Gns made me realise that I had missed something obvious - I was thinking exclusively of autofs.
The BSD automounter, am-utils (formerly amd), doesn't suffer from some of the race conditions that autofs has. It is subject to the limit on the number of unnamed devices, but will prove more reliable if you want a low expiry time.

The biggest cons of am-utils are:
a) performance - programs that use a directory name that includes an am-utils mount point are slowed down by being serialized inside am-utils. This affects very few programs.
b) It can't do mount-in-place. (Well, it can on some systems, but we have to avoid it is to avoid the buggy IPC mechanism.)
c) /bin/pwd returns the dynamically created directory, which can break 'at' jobs.

On the other hand, it is conceptually simpler, it is tried and tested, and it is reliable.

msnr:
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
EXPERTS:
Post your closing recommendations!  No comment means you don't care.

This question has been classified abandoned. I will make a recommendation to the moderators on its resolution in a week or two. I appreciate any comments that would help me to make a recommendation.
 

Unless it is clear to me that the question has been answered I will recommend delete. It is possible that a Grade less than A will be given if no expert makes a case for an A grade. It is assumed that any participant not responding to this request is no longer interested in its final disposition.

 
If the user does not know how to close the question, the options are here:
https://www.experts-exchange.com/help/closing.jsp
 
drewber

The issue has been resolved in Clearcase 2002.05.00 - patch 8. I would recommend you patch your system to at least 21 & 22. Additional Linux improvements were seen in patch 17 as well.

Unfortunately the original poster did not leave the Clearcase version, but I suspect it's either 4.0
or 4.2 -- neither of these versions had truly full LINUX support until 5.0 came out in November of 2001...and even then, until the patches I mentioned, since Linux wasn't seen as a truly viable business product by Rational until the end of 2001.

Cheers,
        -Red

No comment has been added lately, so it's time to clean up this TA.
I will leave the following recommendation for this question in the Cleanup topic area:

Split: ahoffmann {http:#7205906} & Gns {http:#7210411} & pjb1008 {http:#7249127}

Please leave any comments here within the next four days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

paullamhkg
EE Cleanup Volunteer

Despite the admins pot-luck guess, if anyone with Clearcase on Linux reads this string, you'd be wasting your time trying any of the suggestions until you've updated your copy of Clearcase.

You can read the issue for yourself on the Rational knowledge base at :

http://www-306.ibm.com/software/rational/support/