Sun-Spots Digest, v6n48
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sat Apr 9 02:57:21 AEST 1988
SUN-SPOTS DIGEST Thursday, 7 April 1988 Volume 6 : Issue 48
Today's Topics:
Re: Whining disk drive (5)
Re: Problems reading others' TAR tapes on a SUN
Re: Sun Quarter Inch Cartridge tape questions
Sun 4 compiler glitches?
Questions about backups
Commercial backup systems for Suns?
Request for info on helical-scan tape units
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 stored on "titan.rice.edu". For volume X, issue Y,
"get sun-spots/vXnY". They are also accessible through the archive
server: mail the word "help" to "archive-server at rice.edu".
----------------------------------------------------------------------
Date: Tue, 29 Mar 88 11:18:13 PST
From: Mark Foster <fosterm at ogcvax.ogc.edu>
Subject: Re: Whining disk drive (1)
Reference: v6n36
I've encountered this on a number of 5.25" drives; I'm not sure if it
applies to your model.
On some drives, the drive motor spindle bolt is pressed on by a spring
steel pressure plate that is mounted on the interface PCB. The scream is
due to slight friction between the pressure plate's rubber bushing and the
top (bottom?) of the spindle.
I generally suspect that the scream doesn't develop until either a small
divot is formed in the rubber bushing (forming a "cup" that oscillates on
the spindle) or the rubber hardens.
My solution is to put a *very small* amount of grease (we use "Wonder
White Grease" from Sta-Lube/Compton, CA 90221) on the spot where the
rubber bushing contacts the spindle bolt.
Mark Foster
CSE Systems Support
Oregon Graduate Center
Beaverton, OR
fosterm at cse.ogc.edu
------------------------------
Date: Tue, 29 Mar 88 12:19:50 +0200
From: mcvax!corto.inria.fr!vassili at uunet.uu.net
Subject: Re: Whining disk drive (2)
Reference: v6n36
There are two sources of noise in shoebox drives: the disk drive itself
and the ventilating fans. To find if one of the fans is causing the noise
try obstructing the fan exhaust to see if that affects the whine. If it
does then the fan bearings are worn out and you should change it (they
aren't that expensive). If you do replace it, try to use one with metal
blades as plastic ones tend to be more noisy.
If the fan test fails, then it is the disk. A disk with faulty bearings
should be replaced while it works so that you can salvage the data without
going through the tape ordeal (I am not against backups, but a standalone
disk format and file restoration from tape is a real pain). You may also
be able to send the drive for repair; check with your vendor.
Having said that, I can offer a temporary suggestion to stop the whine:
Shut down the drive, and try reorienting the whole shoebox. (i.e. if the
shoebox is standing on its narrow side (vertically) rotate it so that it
rests horizontally, and vice versa). If the noise stops then the wear on
the bearings is lessened and the drive should work for a long time.
However, don't come to me if it suddenly dies.
Good luck
vassili at corto.inria.fr
[[ In the case of the Micropolis drive, there is a third possible source
of the noise. Read on... --wnl ]]
------------------------------
Date: Tue, 29 Mar 88 07:29:34 PST
From: hyder%hub at hub.ucsb.edu
Subject: Re: Whining disk drive (3)
Reference: v6n36
The "whining" noise on Micropolis drives is almost always from the
anti-stat bushing. This is a round carbon bushing on a spring clip in the
middle of the disk circuit board, it rides on the disk spindle and is
there to keep static potential equalized. It also wears with age, i.e.
noise gets worse, until it makes a sound that is painful and, to me,
sounds like early disks did just before they crashed. (Stopping to think,
this sound is the main reason I use Maxtor disks.)
If it is the bushing there is nothing wrong with the disk. If you're
comfortable taking the shoebox apart, the fix is easy but short term and
sound cosmetic: replace the bushing. The sound will return as the new
bushing ages. The bushing is attached by one small screw. In many cases
a short term solution is available: re-align the bushing to a less worn
spot. (It will probably take you a while to find these bushings, start
with an authorized dealer that is a repair site.)
Paul Hyder
...ucbvax!ucsbcsl!blueox!hyder
hyder at sbitp.bitnet
hyder at hub.ucsb.edu
(A number of places I know of actually remove the bushings from Micropolis
drives on arrival for this reason. Please don't do this without checking
with Sun! If you do remove the bushing make sure ALL available grounding
points are properly grounded.)
------------------------------
Date: Wed, 6 Apr 88 09:37:30 PDT
From: ho at tis-w.arpa (Hilarie K. Orman)
Subject: Re: Whining disk drive (4)
Reference: v6n36
Micropolis says the noise is due to an unnecessary ground spring. The
drive can be unbolted from the box and the spring removed without any
adverse effects. They will describe the location of the spring in more
detail if you call them.
------------------------------
Date: Mon, 28 Mar 88 18:31:25 CST
From: vixen!ronbo at cs.utexas.edu (Ron Hitchens)
Subject: Re: Whining disk drive (5)
Reference: v6n36
Yes, I have an explanation, and a fix. Actually two possible fixes.
The whining is caused by a little copper strip attached to the logic board
on the bottom of the drive. It has a carbon pad on it which makes contact
with the end of the motor spindle, which pokes through a hole in the
circuit board. The purpose of the little metal strip is to drain off
inductance which could be built up as the disk platters spin through the
earth's magnetic field. For larger disks (8" and up) this can be
significant, but for 5.25" drives it's seldom a problem. The obnoxious
sound you hear is the little metal strip vibrating at a resonant frequency
(Micropolis seems to have designed it with the optimal shape for annoying
vibration :-). The resonant vibration rattles the logic board and is
amplified by the drive case and the shoebox itself. As the drive runs,
the rotating spindle slowly wears a little dent in the carbon pad, which
causes the curved metal strip to subtly change shape. If it changes such
that it becomes resonant with the vibration caused by the drive spindle,
it starts making that terrible racket.
There are two ways to fix it. The simplest and most reliable is to simply
remove the strip altogether. I've done so on a couple of drives, without
any ill effects. If you're concerned about circumventing a feature the
engineers saw fit to design into the drive in the first place, you can try
bending and reshaping the little metal strip slightly in an attempt avoid
the resonant vibration. This can be a very tedious operation but may
yield success if you're patient enough.
To make the fix, you'll need to open the shoebox, remove the drive and
partially remove the drive's logic board. I won't go into all the gory
details of how to do so, if you aren't already sufficiently confident in
dealing with hardware to figure it out yourself, you're better off getting
someone who is to do it for you. Do be aware that you'll void your
warranty if you have one.
Ron Hitchens ronbo at vixen.uucp hitchens at cs.utexas.edu
------------------------------
Date: 27 Mar 88 20:29:11 GMT
From: umix!oxtrap!rich at uunet.uu.net (K. Richard Magill)
Subject: Re: Problems reading others' TAR tapes on a SUN
Reference: v6n34
> ...can anyone tell me how to extract from a 1/4 inch cartridge,
> written on a MASSCOMP, from a SUN?? I had no trouble whatsoever
> reading and writing tapes between Masscomp and Intel machines, but
> am unable to read the tape on a Sun. Any ideas??
Yes. Use /dev/rst8. I've passed a number of tapes from burroughs xe550,
(really a ct megaframe), masscomp, sun, sequent, tower, apollo, etc.
Nearly everyone, (except 3b2's which use a different encoding), uses QIC
24 as their default.
Sun uses QIC 11, (/dev/rst0), for distributions, although I can't see why,
but they do provide QIC 24 in the form of /dev/rst8. (man 4 st).
Some machines, (some towers), byteswap the tar/cpio archive so you have to
dd swab them off the tape. Ansii headers are a pain for unix. tar is the
easiest format, (what with pd-tar and all).
Two hints... Remember to retension the tape *prior* to using it on a new
drive. Some drivers do this every time you load a tape, others only on
request. (man 1 mt). Also, you can't just cat from one drive to another
to copy tapes. (buffer sizes, I'm told, I don't have source). Instead,
you must dd (man 1 dd) them and if you machine swabs, it's anybody's guess
what the output byte ordering will be.
------------------------------
Date: Mon, 28 Mar 88 19:21:57 CST
From: vixen!ronbo at cs.utexas.edu (Ron Hitchens
Subject: Re: Sun Quarter Inch Cartridge tape questions
In recent digests cmcl2!ll-xn!atexrd!mikeh at rutgers.edu (Mike Harris) in
V6n34 and sf at lanl.gov (Steve Finn) in V6n37 asked similar questions about
exchanging QIC (Quarter Inch Cartridge) tapes between Suns and other
systems. Neither was having any luck. My guess is that they're using the
wrong recording mode on the tapes.
The standard Sun3 QIC drive supports two recording modes, known as QIC-11
and QIC-24, these correspond to the /dev names rst0 and rst8. Most people
probably routinely use /dev/rst0, since that is what you use to read Sun's
distribution tapes (QIC-11). It's also the only mode many Sun2s support.
Unfortunately, QIC-11 is an old standard, which has been replaced with
QIC-24 and is seldom used anymore, except for backward compatibility the
way Sun does with their distribution tapes. Most of the rest of the world
uses QIC-11 only.
Chances are, you'll be able to read QIC tapes from other systems if you
use the rst8 device, such as:
tar xvf /dev/rst8
or dd if=/dev/rst8 of=foo
And other systems should be able to read tapes written on a Sun with the
rst8 device, such as
tar cvf /dev/rst8 foo baz bop
or dd if=foo of=/dev/rst8
Tape read/write errors are very rare with QIC, because of the way data is
written on the tape, QIC is a very different animal than a 9-track tape.
A tape will appear to be totally unreadable, however, if it is written in
one format and you attempt reading it as the other.
There isn't space here for a full explanation of how QIC tapes work, such
as the serpentine recording method, the block formatting, the error
correction scheme, streaming vs non-streaming behavior, etc. If I get
some spare time I may write something up, since I see a lot questions
about QIC tapes in this digest. Once you see how QIC drives work, most of
the mysteries disappear.
Ron Hitchens ronbo at vixen.uucp hitchens at cs.utexas.edu
------------------------------
Date: Sun, 27 Mar 88 12:31:23 PST
From: blueox!hyder at hub.ucsb.edu
Subject: Sun 4 compiler glitches?
Have been doing a bit of work with a Sun 4 in Sacramento and keep bumping
into strange behavior as I (im)/port utility code. Most of these have
traced to C compiler "code gen errors" or optimization "garble". This is
an initial software release so my question is: Is there an update of this
C compiler that is less glitched? If so what version number do you trust?
If anyone has suggestions, please let me know.
TIA,
Paul Hyder
...ucbvax!ucsbcsl!blueox!hyder
hyder at sbitp.bitnet
(hyder at hub.ucsb.edu -
may work, this DDN link has been having problems)
FYI on this version of the compiler when code fails my first step is to
make sure that the optimizer(aka optimixer) is turned off. (This is
vanilla code, like Mh and GNUemacs, that is set up to use the optimizer on
Sun3's.) The "garbles" usually produce code that core dumps. Optimization
seems to occasionally cause similar behavior in f77.
Have also run into some strange behavior that has traced to default return
value from subprogram calls, if you don't explicitly set it sometimes this
compiler returns 0 sometimes 1. (This is WITHOUT optimization. It's
usually corrrect but once in a while... The first place I found this
behavior was in the "fsplit" utility, the return value problem meant that
it wouldn't properly attach names to the split files.)
------------------------------
Date: 28 Mar 88 16:21:51 GMT
From: moss!ihlpa!elel at rutgers.edu (Edberg)
Subject: Questions about backups
I am in the process of designing a backup program to manage backups on our
IHCC SUN computers. Our configuration initially will consist of about 9
SUNS that each have 5 900MB (a guess) disks. There will be 3 tape drives
available in the network.
I have enhanced our std SV backup program (DELTASAVE) to schedule various
levels of dumps for each FS on each system. The program then guides the
operation staff on what media to mount, when and where.
Part of the DELTASAVE program is responsible for VERIFYING that the LABEL
on the tape matches what is supposed to be currently mounted (SV
/etc/labelit or volcopy format). This ensures that backups are being
written to to proper backup media.
1) Does the SUN /etc/dump command have similar LABELING capability ?
Is there a way to internally label a DUMP tape so the program
can verify that the correct tape was installed in the TAPEDEV
before OVERWRITTING the wrong tape media ?
We are also interested in optimizing backups by performing incrementals
'on-line' to a backup server (a UTS or VAX system). Part of this
enhancement would rely on generating a file name list. This program
currently exists (SV) and is based on the /etc/ff command to generate a
file list dependent on a date stamp (last successful backup for that FS).
SUN does not have a compariable command that reads the RAW fs structure
that I know of.
2) is there a SUN command that reads the RAW fs structure that
could generate a file list using `date stamp` criteria
similar to ff ? This will have to work on 3.x systems and
and 4.0 systems (we have both to support).
I could use the "find" command but that would change the
existing program more than I wanted to. (I will have to
use it unless something else turns up)
One final question:
3) Is it possible on a CENTRAL system to perform a DUMP of
a REMOTE file system (not mounted locally normally)
e.g., dump xxx ihero:/dev/rxxx
I know you can do a dump of a local FS to a remote TAPEDEV
using 'rdump', but the goal is to simulate a central
SERVER that perform dumps on its local file system in addition
to remote file systems from other systems.
Eric Edberg
ihnp4!ihlpa!elel
(312)979-4382
------------------------------
Date: Mon, 28 Mar 88 10:58:18 EST
From: czei at osupyr.mast.ohio-state.edu (Michael S Czeiszperger)
Subject: Commercial backup systems for Suns?
We are faced with an ever-growing sun network where the backup problems
will only increase. If anyone has come in contact with a commercial or
otherwise backup system that meets the following criteria, please let us
know.
Criteria for backup procedures:
1. Must be able to keep track of what file was written on what tape.
2. Must work over the network to backup machines with no tape drive.
3. The configuration should be flexible enough to handle several
servers and dozens of machines which may or may not have their
own disks.
4. Must include a clear tape labeling system.
5. Must be easy enough to use that even workstudy students can't
mess up.
Thanks to all respondents....
Michael S. Czeiszperger | Guest account courtesy of Math Dept.
Systems Analyst | Snail: Room 568 Dreese Labs (614)
Dept. of Electrical Engineering | 1971 Neil Avenue 292-
The Ohio State University | Columbus, OH 43210 0161
cbosgd!osu-cis!osupyr!czei | czei at osupyr.mast.ohio-state.edu
[[ Please summarize your findings here. I'm sure that many managers of
Sun networks will be interested. -wnl ]]
------------------------------
Date: 25 Feb 88 20:34:36 GMT
From: rushton at stsci.edu (a. m. rushton)
Subject: Request for info on helical-scan tape units
We are planning to buy some of the new high density helical-scan tape
units (such as the Gigastore, Exabyte, or TTI units) for use in backing up
Sun 3/280 fileservers. However, before we buy, we would like very much to
get feedback/recommendations/advice/etc from others who have used them.
Any potentially useful information would be appreciated.
I read Sun-Spots regularly; however replies directly to me would be
better. I'll summarize responses to the net later. My address is:
rushton at stsci.edu Internet
Many thanks in advance.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list