I've just installed Plan 9 on a new terminal that will soon become my
new auth/cpu/file server. It's a PIII@1Ghz, 128MB of RAM, and a 500GB
hard drive. I made a 10GB fossil and gave the rest to venti. When I
boot, I find that pretty much all of the 128 megs is being used, and
of course since swap doesn't work I didn't even bother to make a
partition for it. Besides the obvious "buy more RAM", do you guys
have any suggestions for reducing memory use? I have run Plan 9 on
machines with 32 MB in the last few years so I presume this must have
something to do with the size of the file system

i don't think i'd go as far as that for a cpu server, or even a terminal.
(paging over the net is tedious, but better than shutting things down
on overload.) file servers should be configured not to page (there is no need).

venti(8) has a very good discussion of memory usage and how to tune it.
But there doesn't seem to be any way of displaying the memory usage of a
running venti so it's going to take some trial and error to come up with
the right values.

--lyndon

I just remembered, I've got an old Nextstation Turbo Color under my desk...
I know there was a port for it at one time...

Does anyone still have the sources? I didn't see them on the kernel history site.

Thanks in advance!

I tried setting mem, bcmem, and icmem all to 1M but no improvement.
They are not set by default, and trying the configuration shown in the
man page actually prevents the system from booting (out of memory).

John

490 GB of venti storage is 900 arenas or so, and venti
requires having at least two disk blocks in its buffer
cache for each arena. At 8k disk blocks, that's going
to be about 16MB just for those blocks, no matter
what you set bcmem to.

I haven't studied this in detail, but I think that if you
made larger arenas (say 1.5GB instead of 0.5GB)
then you'd end up with less memory usage by venti.
That would require starting over, of course.

perhaps i'm pointing out the obvious. have you tried something as simple
as ps to identify culprits?

ps -a|sort +4nr|sed 10q

on my system, i get

(names changed to protect the guilty)

xxx 151013 1:48 0:21 346784K Pread fs ?
yyy 157084 0:11 0:03 299780K Pread fs ?
yyy 162896 0:04 0:01 281240K Pread fs ?
zzz 158720 13:31 2:09 132616K Pread fs ?
[...]

suprise, suprise. it's upas/fs leading the charge.
(the leading upas/ is of course dropped from the fs entries,
just as it would be for /bin/ls.)

I have a CPU/Auth server set up. I'd like to be able to add users remotely (via drawterm), rather than at the system's console. However, normally, I can't attach to /srv/fscons, and as I found, can't start another fscons and open the filesystem under it.

/srv/fscons gets created at startup, by bootes:

cpu%% ls -l /srv/fscons
--rw------- s 0 bootes bootes 0 Aug 6 12:09 /srv/fscons
cpu%%

Since I'm not logged in as bootes, and am not a member of the bootes group, I can't use con to connect to /srv/fscons, and therefore, can't add a user.

I read in chgrp(1) that you can't change file group membership when the fileserver is not in the bootstrap state. How then can I get the /srv/fscons to belong to the 'sys' or 'adm' groups? Or is the generally accepted solution to add my account to the bootes group, then chmod g+rw /srv/fscons (from the console)? Would that even allow me to connect to the fscons from a drawterm session?

I understand the concept of no superuser and un-circumvent-able security, but someone's got to be able to do administrator-type things w/o taking a trip to the server room...

Thanks much in advance!!

-Ben

When you drawterm, authenticate as 'bootes' instead of your usual id.