itty bitty IRIX questions
Rodian Paul
rpaul at crow.UUCP
Sun Jun 2 13:22:25 AEST 1991
Randy Carpenter asked:
> | 2.) Why does ps(1) take so long every once in a while but then
> | has good response at other times.
Dave Olson answered:
> If you change /unix, or remove /tmp/.ps_data, the file gets re-created,
> which takes a while. After that ps runs faster. Basicly it saves ps
> having to grub through the kernel symbol table on each invocation.
>
Myself and others here have also noticed this problem. We don't dick
with the kernels that often and to my knowledge nobody deliberatly
trashes /tmp/.ps_data. I'm afraid I don't think that the above
answer quite explains why the response is often so slow. The odd
thing is that the response problem doesn't seem tied to the load-average
on the machine.
The machines we've noted this on: 4D/70GT's, 4D/210's, 4D/240GTX's, 4D/25's,
4D/35's and a 4D/380S.
OS: IRIX 3.3.1 and 3.3.2
> | 3.) Why doesn't ex(1) and vi(1) look at the TMPDIR environment
> | variable like ed(1) to allocate buffers? The default root
> | partition on SGI systems doesn't leave enough space in /tmp
> | to edit huge files. I don't want to have to worry about
> | every user having to "set directory=/usr/tmp" in their .exrc
> | files and I don't want to expand the root partition.
>
Now for a naive question. I collect a lot of stuff from the net and the
folders that I save via 'rn' often become quite large. At a later date,
when I try to run:
% Mail -f ~/News/Comp.foo
on a large file, I get the following response:
/tmp: No such file or directory
I then have to switch to a machine with a larger root partition. I find
that nowadays I am slicing my news folders and giving them a .n suffix.
Is there a way to specify which directory /usr/sbin/Mail uses for a
temporary dir? Yep. I'm allready specifying TMPDIR in my env.
Cheers.
-------------------------------------------------------------------------------
rpaul%crow at ccut.cc.u-tokyo.ac.jp phone: +81 (3) 5706-8357
ccut.cc.u-tokyo.ac.jp!crow!rpaul FAX: +81 (3) 5706-8437
More information about the Comp.sys.sgi
mailing list