Sun-Spots Digest, v6n57
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Apr 19 02:09:47 AEST 1988
SUN-SPOTS DIGEST Monday, 18 April 1988 Volume 6 : Issue 57
Today's Topics:
Re: Can backups be done with system in multi-user mode (2)
Re: 8mm video-tape for backups
Re: More information on 892 MB drives (and a big problem)
Memory Modules for Sun 3/60's
Timeshared Suns - some experiences
Interested in known DNI bugs.
3rd party SCSI hosts adaptors needed
Sun 3/50 clock keeps resetting
Sun4 Optimixer problems?
Longer host names in rcp/rdump?
'cp' silently failing on NFS filesystems?
mail from uuxqt?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sat, 09 Apr 88 11:26:47 EST
From: davy at intrepid.ecn.purdue.edu (Dave Curry)
Subject: Re: Can backups be done with system in multi-user mode (1)
Reference: v6n49
>From: montnaro at sprite.steinmetz.ge.com (Skip Montanaro)
> the problem with multi-user backups is that a directory inode might get
> deleted and then reallocated between dump passes.
I posted mods to 4.3BSD dumptraverse.c about a year ago to the net to fix
this so that you can safely dump live file systems (we do it all the time
on 16 VAXes, 4 Goulds, and about 10 Sun servers, and have been for about
2.5 years with no problems). If there's enough interest, I can send them
to Sun-Spots too; they're short.
(and our illustrious moderator comments....)
> I suppose it would be possible to write a signal handler that could write
> unrecoverable information (such as open files, signals, etc.) out to a
> file before dumping core...
I did this once on our VAX 4.3BSD systems. It's in the form of a library
called "chkpt" (checkpoint), which allows the user to call it and save his
program, and also catches SIGTERM and saves the program automatically.
The program is saved in executable form (0407 file, unfortunately) in the
file "chkpt.dat" with it's start point set to an environment restoration
routine. So, the user can simply execute "chkpt.dat" to restore his
program.
When the user executes "chkpt.dat", the program reopens all its files,
seeks to the right places, resets its signal handlers, and so on, and then
picks up execution right where it left off. Pretty much everything the
user could possibly do system-call wise is restored. The idea was to
allow long-running programs to make themselves relatively immune to
shutdowns and system crashes.
I've never ported it to the Suns because not too many people were ever
interested in it on the VAXes. It should be fairly simple though; you'd
need a source license (or need to know a lot about how the C library
system call interface works) and have to write about 5 lines of assembly
language to save and restore the stack pointer, frame pointer, and program
counter.
--Dave Curry
Purdue University
------------------------------
Date: Mon, 11 Apr 88 11:13:09 -0400
From: dan at wilma.bbn.com
Subject: Re: Can backups be done with system in multi-user mode (2)
Using SIGQUIT won't work both because you can't continue programs you've
core-dumped, only restart them (with undump), and because many programs
ignore SIGQUIT. SIGILL might be better--assuming the program has no
handler for it...
Here's a different idea: what if you sent long-running processes SIGSTOP,
did the dump, then sent SIGCONT? Then there should be no way a directory
inode can be deleted and reallocated between passes.
I've had a good deal of success with careful use of "kill -STOP" and "kill
-CONT" when I wanted to stop some long-running massive job for a little
while so I could use memory and/or CPU cycles. I always sent the signal
to the youngest or almost-youngest child in the process stack, not to any
of the others. I am not sure how easy it would be to automate this. But
maybe sending SIGSTOP to everything except your own process tree would
work ok.
Dan Franklin
dan at bbn.com
------------------------------
Date: Fri, 8 Apr 88 20:51:47 EST
From: umix!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Re: 8mm video-tape for backups
Reference: v6n45
milano!sandel at tuvalu.sw.mcc.com (Charles Sandel) writes:
>I have evaluated the Exabyte 8mm videotape backup system from Delta
>Microsystems. It works very well....
and proceeds to give an thorough and largely positive review. I'd like to
second his remarks, and add a few.
We are using an Artecon-assembled 8mm drive. Like the one he describes
the drive mechanism is by Sony, the controllers and other electronics are
by Artecon. In all our research on 8mm drives they have all come down to
these two manufacturers.
The Artecon unit came with tape driver software for SunOS 3.4 and earlier.
Our unit works with the standard 3.5 /dev/st device -- no driver needed.
We *did* have to disable SCSI disconnect in the kernal (which degraded
system performance) but this is fixed in a later release of the controller
boards.
Thus far our testing results match his, but we have only tested on the
3/50.
Throughput is reasonable -- not great, not terrible. Our preliminary
figures say we can back up a 1.4GB server between midnight and 7AM, which
is all we're aiming for. Thus far it looks slightly faster than
cartridge, slower than magtape. We're ordering a unit for our servers,
and will post performance data when we have more. We expect backing up
SMD disks to SCSI tape will perform better than SCSI disk to SCSI tape.
To "torture-test" the drive we've been doing 3-4 backups per day for about
a month, using the same tape. No problems so far.
The unit we have is a standalone "shoebox" style. We hooked it in series
with our existing cartridge drive and are able to use both with no
conflicts.
>I am convinced that the drive and the electronics work. My big concerns
>here are all about the media itself (the tape)...
>the low cost of the tapes ... at $8 apiece for 2Gb of storage
This is the primary attraction for us. We can cut our media costs by at
least 75%.
On long-term storage: nobody knows. The vendors predict reasonableness,
but the real answer will come when someone picks up a five year old tape
and tries to read it. We use a vault for long-term storage so rust
probably isn't a problem, but when was the last time you (or anybody else)
retensioned a 5-year old tape from a vault? Or tried to read one, for
that matter?
Steve Simmons
UNIX Systems Mgr.
Schlumberger CAD/CAM
scs at lokkur.uucp
[[ Although I hate to admit that I have such experience, I used to put
long term backups for a Heathkit computer onto cassette tape. Reliability
of the medium was vastly improved when we started buying medium-high
quality tapes (specifically, Maxell UD tapes instead of Radio Shack). In
short, the better brand name tapes should last longer so the slightly
higher price should be worth it. --wnl ]]
------------------------------
Date: Mon, 11 Apr 88 15:05:10 N
From: Johan Widen <jw at sics.se>
Subject: Re: More information on 892 MB drives (and a big problem)
We have acquired two NEC D2363 drives together with an Interphase
controller and driver routines from Holistic Technology. We seem to get
considerably more than 892 MB from our drives. Our drives are formatted
with
1021 cylinders + 3 alternates
70 sectors per track (no sector slipping)
This comes out to (there are 27 heads):
1021*70*27*512 = 988001280 bytes
while Sun (who do provide for sector slipping) according to the article
in Sun-spots vol. 6.33 provide
964 cylinders + 2 alternates
67 sectors per track + 1 for sector slipping
This comes out to
964*67*27*512 = 892864512
We too, got terrible kB/inode ratios. I have not yet got around to fixing
the mkfs command.
Johan Widen
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
Internet: jw at sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw
------------------------------
Date: Sun, 10 Apr 88 00:34:42 -0400
From: Henry B. J. Krempel <krempel at pacrat.npac.syr.edu>
Subject: Memory Modules for Sun 3/60's
I don't want to cause a rush here, but I got 4MB for my '60 from a
company called Clearpoint. We got it in 2 weeks, put it in ourselves,
and haven't had a problem yet. (a whole month)
Henry B. J. Krempel <krempel at pacrat.npac.syr.edu>
Northeast Parallel Architectures Center (NPAC)
Syracuse University
250 Machinery Hall
Syracuse, N.Y. 13244
------------------------------
Date: Mon, 11 Apr 88 14:20:25 +0930
From: Kevin J. Maciunas <munnari!cs.flinders.oz.au!kevin at uunet.uu.net>
Subject: Timeshared Suns - some experiences
Since there have been many inquiries to Sun Spots about Suns (particularly
4's) as time-shared Unix systems, I thought I might share our experiences
here at the CS dept, Flinders University.
Background:
We have had a 3/280 with 16MB, 32 lines (ALM-1's) and a Super Eagle/451
for about 18 months as a time-shared system for Undergraduate teaching.
We have just installed two more Suns (both 4's, 32MB, 451's etc) to
support all our Undergrad CS students.
Experience: We were forced to buy the Sun-3 with the ALM boards - we
wanted ethernet terminal servers (Encore Annexes).. We got the Annexes
with the Sun-4's and I personally would highly recommend them. Last years
load on the Sun-3 was quite high (it was used only by second year
students) with about 24-30 active users doing program developement in
Pascal and Modula-2 (term I), COBOL [yech] (term II) and SCHEME [MIT
version] (term III). SCHEME in particular was a real test with only 16MB
(how do you say "paging"?) At the same time we had a Pyramid 90x (8MB)
and the same sorts of offered load resulted in load averages of 30+ (how
do you say "S-L-O-W"!). While the Sun-3 certainly slowed down, it was by
no means unacceptable (csh prompts came up virtually instantly).
One interesting note was the fact that the students tended to use pi/px
for their pascal code, one 1,100 line assignment could be compiled under
pi in 4.3 secs (real time) with about 20 or so users on the 3. This
tended to produce quick turn around on the edit->compile cycle,
regrettably omitting the "think" part in between!
Sun-4:
The Sun-4's perform much as we expected. Both the 3 and the two 4's are
I/O limited (wait for the 7053's - they should help things along nicely)
but the 4's cope effortlessly given our job mix. There are a few teething
problems though, three Highlights:
o SunOS3.2L4 NO SUBNET SUPPORT! ARRGGHH.
o " Bug in pty support
o " No pi/px
The subnet support comes in 4.0, the pty bug is that the kernel only
recognises 32 pty's, which makes people with terminal servers unhappy!
[Sun have supplied a fix - we now have 64 usable]. Pi/Px is now
unsupported. This is a minor problem for us for the moment, as pi/px is
quite nice - particularly for first--year pascal assignments etc - heck -
even my final year compiler construction course have used it! Our
(temporary) solution has been to port it from the 4.3 tapes - THIS IS VERY
DIFFICULT TO DO. Any one wanting the "ported" version can contact me
direct.
Conclusion:
While you certainly can't jam 100's of users on a Sun-4, given a hefty
boost in the I/O dept, you could put 60 or so. We run very nicely indeed
with 30->48 users with no problems.
/Kevin
Kevin J. Maciunas ACSnet: kevin at cs.flinders.oz
Discipline of Computer Science, Internet: kevin at cs.flinders.oz.au
Flinders University, UUCP: ..seismo!munnari!flinders!kevin
South Australia, 5042. 'phone: +61 08 275 2129
------------------------------
Date: 11 Apr 88 21:56:16 GMT
From: laic!darin at decwrl.dec.com (Darin Johnson)
Subject: Interested in known DNI bugs.
I would like to know of bugs with the Sunlink/DNI package (DECnet). It is
possible that it may have crashed one of our vaxes awhile back.
(does anyone know of a 'user' at sun.com to mail questions like this to?)
Darin Johnson (...ucbvax!sun!sunncal!leadsv!laic!darin)
(...lll-lcc.arpa!leadsv!laic!darin)
------------------------------
Date: 11 Apr 88 17:21:59 GMT
From: dck at mtunn.att.com (David Kwong)
Subject: 3rd party SCSI hosts adaptors needed
Does anyone know of 3rd party SCSI host adaptors one can plug into the
SUN-3s and SUN-4s ? (I have SUN-4/260s and SUN-4/110s, but I understand
that they use the same cabinets and backplanes as the SUN-3s.) Yes, I know
that they have announced a SCSI shoebox option, but it doesn't allow one
to easily plug another SCSI disk in and get it to work. Thanks in
advance.
David C. Kwong (201)957-2657
------------------------------
Date: 11 Apr 88 21:28:30 GMT
From: ndmath!ndcheg!evan at iuvax.cs.indiana.edu (Evan Bauman)
Subject: Sun 3/50 clock keeps resetting
We've had a Sun 3/50 for just about a year, and lately, when we reboot we
get a message that the clock has lost 29 days. It also says to please
check the clock and reset. This has only just started happening.
My first guess is that there's a battery that needs replacing. But before
I rip the thing apart, I'd like someone to confirm my diagnosis. If it is
a battery, where should I get a replacement?
BTW, we're running SunOS 3.5. I looked at the patches posted back in
volume 6 #1 of sun-spots and I'm pretty sure we have a different problem.
Thanks in advance.
Evan Bauman
University of Notre Dame
..!iuvax!ndcheg!evan
[[ I think you do have a different problem. The patches in v6n1 fixed the
"creeping clock" bug---the clock would be running too fast or too slow and
would gain/lose a significant amount of time while the system was running.
You should install the patches anyway, if you haven't already. --wnl ]]
------------------------------
Date: Mon, 11 Apr 88 13:19:24 EDT
From: schwartz at gondor.cs.psu.edu (Scott Schwartz)
Subject: Sun4 Optimixer problems?
Several months ago I noticed that nroff and troff didn't work on the
Sun4's here. I submitted a bug report to Sun and to sun-spots. (The
service order number is 143015). Moreover, as was reported to Sun,
compiling the 4.3BSD troff (which runs fine on a Sun3 or a Vax) fails in
EXACTLY the same way the SunOS4-3.2 troff does. Conclusion: a compiler
problem, obviously. I have received no followup information, so I guess
they can't fix it :-)
Sigh. Anybody want to port GCC?
-- Scott Schwartz
------------------------------
Date: Mon, 11 Apr 88 17:08:41 EDT
From: weltyc at csv.rpi.edu (Christopher A. Welty)
Subject: Longer host names in rcp/rdump?
Is there an easy way one can modify rcp (and rdump) to take host names
longer than 10 characters. This is a really annoying bug for people
without src....
Christopher Welty --- Asst. Director, RPI CS Labs
weltyc at cs.rpi.edu ...!rutgers!nysernic!weltyc
------------------------------
Date: Tue, 12 Apr 1988 08:29-EDT
From: Ralph.Hyre at ius3.ius.cs.cmu.edu
Subject: 'cp' silently failing on NFS filesystems?
I was wondering if anyone else has encountered problems with 'cp' on NFS
mounted filesystems. In a few cases, it seems to update the access time
of the destination file, but the contents are not overwritten. I don't
believe any of the servers or networks was particularly busy at the time.
Any clues or workarounds appreciated. Thanks.
- Ralph
------------------------------
Date: Sat, 9 Apr 88 21:07:00 EDT
From: brad at cayman.cayman.com (Brad Parker)
Subject: mail from uuxqt?
I'm on a 3/50 with SUNOS 3.2. Every night root gets mail from uuxqt as
"daemon". We fire up several uucp polls each night from cron. I've also
seen uucp get mail from "daemon". Anyone else seen this or know what's
causing it?
(ps: I know that uuxqt is part of uucp. I understand how and why it is
started - I just don't know why I'm getting mail from it)
From daemon Sat Apr 9 13:46:35 1988
Received: by cayman.Cayman (3.2/smail2.5/12-02-87)
id AA10319; Sat, 9 Apr 88 13:46:33 EDT
Date: Sat, 9 Apr 88 13:46:33 EDT
From: root (Operator)
Message-Id: <8804091746.AA10319 at cayman.Cayman>
To: root
uuxqt cmd () status (exit 0, signal 0)
-brad
brad at cayman.com
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list