🚀 go-pugleaf

carl@doctor.tymnet.com writes:

} We have experienced exactly the same "slow" response.  We have 6 3/280s
} acting as a large NFS system and wanted to use an alternate root/swap/usr
} partition (as a client of another server) in case of catastrophic failure
} of the primary disk on each server.

} It took more than 15 minutes to boot the server as a client of another one
} of our servers.  This is appalling!!!

} -Carl

I had this problem. I'm booting off another workstation since our
fileserver is not yet upgraded to 4.0.

Doing a pstat -T on the serving workstation during boot I found that 100%
of the inodes were in use. Having the user close several windows at this
time enabled the diskless station to complete booting.

Repeating these tests with various kernels on the serving workstation,
under various conditions led me to the conclusion that *during boot* the
serving workstation must require huge number of inodes for the boot
process. After loading the boot with tftp the usage appeared to drop to
much more reasonable levels.

Upping maxusers on the serving workstation helped by increasing the number
of inodes available. Of course this has some detrimental effect on the
user's normal operation if you carry it too far and make the kernel
manipulate huge tables all the time.

My conclusions:

USAGE                   maxusers
Text Processing            4       (graphic equipped machine)
News Server               10       (my poor lil' 386i 8^)
Programming/Dbxtool        8       (graphic equipped machine)
Prog./Dbxtool/Serving one 10       (graphic equipped machine)

Add one or two maxusers for each additional client. Sun's comments in the
config file say one, my impression was two. Your call.

Under 3.5 my fileserver (no graphics) boots 4 clients fine with maxusers
8, but I suspect that under 4.0 maxusers 12 will be more appropriate.

Now, does anyone know why tftpboot uses so much resource? I watched, and
it's just the process of getting that first boot program that does it.
Although it's hard to be sure, my impression was that loading the kernel
took far less resource than tftp'ing the boot program.  And it's much
larger.

Jim Budler   address = uucp: ...!{decwrl,uunet}!eda!jim
                     domain: jim@eda.com
                 compuserve: 72415,1200
voice     = +1 408 986-9585    fax     = +1 408 748-1032