Hello,
we use NFSv3 with Kernel 2.4.20 which works rather well.
While the main directories (/home, $MAIL, /usr etc.) are either local or
mounted from a HA cluster system, we make heavy use of cross mounted file
systems to save calulation scratch data from Bob to Alice:/discs/scratch/.
This normally works flawlessly, but sometimes such a computer (Alice) has
a hardware or kernel error - or is switched off ("halt",=A0[1]) without
ensuring that no other computer still mounts that disc.
This causes then serious problem: While the nfs client (Bob) computer has
no load visible to the user ("top"), is reacts very, very slow. (Until
either the nfs client is rebooted or the server is alive again.)
Any ideas how we can reduce the inpact?
The directories are mouted with these options:
rw,nosuid,nodev,intr,addr=3Dxxx.xxx.xxx.xxx
Part of the problem is probably that our default login scripts have things
like "quota" or "df" which seemingly also check those directories
(which are mounted with "noquota").
We use quota with timeout -2, so after 2 seconds it is KILLed (-9), so one
can at least log-in and the system behaves kind of ok -- though it is
very, very slow.
Any ideas?
Tobias
[1] This can happen if the computer is moved into an other room, the
graphics card is changed, etc.; we don't turn our computers off for fun ;-)
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
http://www.slickedit.com/sourceforge
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Tobias Burnus <[email protected]> writes:
> Any ideas how we can reduce the inpact?
You might perhaps consider using an automounter. Either amd or autofs
should do the job.
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
http://www.slickedit.com/sourceforge
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
On 20 Feb 2003, Trond Myklebust wrote:
> >>>>> " " == Tobias Burnus <[email protected]> writes:
> > Any ideas how we can reduce the inpact?
> You might perhaps consider using an automounter. Either amd or autofs
> should do the job.
We actually us autofs (v4), but I suspect that some of the problems might
even come from it (high kernel load), given the problems we have with it
so far. (Such that `autofs reload' may start more than one userspace
daemon per one mountpoint, which races causes similar problems (and huge
logs).)
Seems as if we have to live with it :-(
Tobias
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
http://www.slickedit.com/sourceforge
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 21 Feb 2003 13:06:25 +0100 (CET), Tobias Burnus <[email protected]> wrote:
> On 20 Feb 2003, Trond Myklebust wrote:
>> You might perhaps consider using an automounter. Either amd or autofs
>> should do the job.
Actually an automounter is not going to help you at all if the
filesystem is already mounted. Certainly not if the culprits are "df"
and "quota", since they both bypass the automounter.
> We actually us autofs (v4), but I suspect that some of the problems might
> even come from it (high kernel load), given the problems we have with it
> so far. (Such that `autofs reload' may start more than one userspace
> daemon per one mountpoint, which races causes similar problems (and huge
> logs).)
You should never have to issue autofs reload, by the way. It rescans its
maps whenever it detects a timestamp change on them.
> Seems as if we have to live with it :-(
More or less, yes. If you *need* to run "df" and "quota" all the time,
you really have no choice.
The best you can do is a manual lazy umount (umount -l), but it really
does have to be run manually on every machine. You can't (easily)
automate it, because umount -l always succeeds, even if the filesystem
is busy.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
http://www.slickedit.com/sourceforge
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
On Fri, 21 Feb 2003, Ion Badulescu wrote:
> You should never have to issue autofs reload, by the way. It rescans its
> maps whenever it detects a timestamp change on them.
Only if you don't change auto.master, since the init scripts
scans auto.master and for each entry starts a new automount process.
> > Seems as if we have to live with it :-(
> More or less, yes. If you *need* to run "df" and "quota" all the time,
> you really have no choice.
Well, we don't need to, but our users have the tendency to have to much
data - therefore we need to check the quota for $HOME.
> The best you can do is a manual lazy umount (umount -l), but it really
I will try this the next time a computer really crashes hard.
Thanks for the tips,
Tobias
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
http://www.slickedit.com/sourceforge
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs