Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/08/88)
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@rice.edu Send subscription add/delete requests to: sun-spots-request@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@rice.edu". ---------------------------------------------------------------------- Date: Tue, 29 Mar 88 11:18:13 PST From: Mark Foster <fosterm@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@cse.ogc.edu ------------------------------ Date: Tue, 29 Mar 88 12:19:50 +0200 From: mcvax!corto.inria.fr!vassili@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@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@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@sbitp.bitnet hyder@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@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@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@vixen.uucp hitchens@cs.utexas.edu ------------------------------ Date: 27 Mar 88 20:29:11 GMT From: umix!oxtrap!rich@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@cs.utexas.edu (Ron Hitchens Subject: Re: Sun Quarter Inch Cartridge tape questions In recent digests cmcl2!ll-xn!atexrd!mikeh@rutgers.edu (Mike Harris) in V6n34 and sf@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@vixen.uucp hitchens@cs.utexas.edu ------------------------------ Date: Sun, 27 Mar 88 12:31:23 PST From: blueox!hyder@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@sbitp.bitnet (hyder@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@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@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@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@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@stsci.edu Internet Many thanks in advance. ------------------------------ End of SUN-Spots Digest ***********************