I gathered very little extra information on this subject.
Someone suggested that I should never reformat a SCSI disk. I don't
agree, I do it twice a year in average on my Macintosh, for one reason
or another (major system upgrade, some unidentified problem,
whatever), without any problem. Besides, I'm not sure that all SCSI
drives do automatic bad sector remapping. For those that don't,
formatting would be a necessary step every now and then. Anyway, if
things don't work as expected with a SCSI drive, the only recourse you
have is to reformat it, to try and restore things to normal.
A reasonable explanation for the garbled df output could be the
following:
> occurrences, in an endless way, till you give up. "df" is then
> inconsistent (all/most filesystems with 42% usage).
Remember, your root is still mounted read-only, and therefore, your
/etc/mtab has not been cleared out from the previous (probably
multi-user) operation. "df" is going to show everything in /etc/mtab,
but there will actually be only the root mounted, so the fsstat for
each mount point will actually return figures for the root filesystem.
As for the format command not doing any useful work, the following is
significant:
>1- Formatting these drives on any machine is a "frustrating"
>experience: the format command does very little, if any. It returns
>in a few seconds (obviously nothing serious can be done in this time
>frame). After a format command, the filesystem is usually intact
>(with all previously existing files...).
>
This IS correct behavior for the small Quantums. If it detects that the
existing format is the same as the new format it is attempting, it does
nothing.
I can't check it right now, but I think that formatting the quantum on
a Macintosh using the formatting utilities I have will cause real
formatting to take place. I may have to reformat a 105 Quantum on the
mac in the near future and will be able to sort this out.
Another hint about the whole problem:
I have seen some SCSI drives get into real problems after reformatting.
Something with SunOS format and defect lists. At least with previous
OS levels. E.g. *never* analyze a disk with 4.0.3. If analyze finds some
error, and adds it to the defect list, you'll never be able to reformat it.
Well, it might be true, but why do the drives always magically
"ressurect" after being powered up on a sun4c machine? I don't even
need a newfs or a format. Fsck will run cleanly as if nothing had
happened. It's clear that something with regards to the interface
SCSI drive -- CPU gets garbled on a 4/3xx machine, but is correctly
dealt with on a sun4c machine.
--------------- original question ---------------
Due to our severe disc space shortage, I was forced to put a bunch of
105 Quantums on our servers (4/390 and 4/330). The setup does work,
but not entirely.
The 4/330 is supposed to support SCSI discs, but it does not seem to
support the little Quantums. The 4/390 is *not* supposed to support
them, but the behaviour is not much different.
Since these drives were already being used as resource holders hosted
in desktop stations, I already had them ready to just snap them in the
SCSI chain (i.e. I didn't need to reformat/newfs them). I must add
that I've never observed read/write problems with these drives, so
cable length shouldn't be an issue. On the 4/330, the single Quantum
is housed in a showbox beside a Wren-4; on the 4/390 I inserted four
extra connectors on the long SCSI tape cable.
I'll relate the bits of experience I've gathered so far with these
drives (apart from the occasional sticktion, of course...):
1- Formatting these drives on any machine is a "frustrating"
experience: the format command does very little, if any. It returns
in a few seconds (obviously nothing serious can be done in this time
frame). After a format command, the filesystem is usually intact
(with all previously existing files...).
2- newfs works fine if the drive is hosted by a desktop machine, but
on any of the above mentioned servers newfs either works through
completion but does nothing or fails stating something about not
enough space (not enough blocks, after the last superblock number).
Unfortunately, I'm not sure if I ever successfully newfs'ed any of
these drives on a server (takes quite some time...).
The above is not much of a problem, except when disaster strikes (that
is, when the electricity company decides to play with the power
lines:-). Normally fsck will fix whatever gets broken, with
an occasional manual intervention (automount is usually the culprit,
those soft links are hell...).
Recently, however, things have not been gone smoothly after an
unpredicted power outage. Fsck will choke on one or more of the
quantums (all of them with a sole partition), *but* --- the partition
gets mounted, with the system in single-user (it shouldn't, should
it?). Fsck -y will then spit everything it can about "DUP"
occurrences, in an endless way, till you give up. "df" is then
inconsistent (all/most filesystems with 42% usage).
The only way to get a working system is to comment the partition out
of fstab). As said before, formatting does nothing, and so does
newfs. The only recourse is to take the drive to a sun4c machine and
issue the newfs there.
The last time I had to deal with the problem had an interesting twist.
After booting the sun4c host format wouldn't find the drive for me to
see whether there was any media problem (which I do under these
circumstances). Looking back at the boot messages I noticed that
the kernel recognized the drive but had problems with the info from
it:
May 9 16:59:36 s1d vmunix: sd0: Vendor 'QUANTUM', product 'P105SS', (unknown ca
pacity)
After invoking format for a few times it finally recognized the drive.
I did a quick read test and fsck'ed the partition with no problems
whatsoever. It's been mounted ever since, all contents OK...
I checked the list of fixes posted to the lsit some time ago and
didn't find any fix related to SCSI disks, apart from the one that
allows for >1GB discs.
Now, I realize that this setup is not usual, and also that the 4/390
does not officially support SCSI discs. However, these drives are
SCSI drives delivered by Sun and the 4/330 supports SCSI drives (the 330
machine has 3 Wren-4's and a single 105 Quantum, and this one already
presented the problem once). I *should* be able to work with this
setup.
Any insights are welcome. Funds for more disc space have been promised
but not delivered for a long time already. That's the way things work
over here, unfortunately.
Thanks,
-- postmaster/manager Paulo L de Geus INTERNET:paulo@dcc.unicamp.br Depto de Ciencia da Computacao DCC - IMECC - UNICAMP caixa postal: 6065 13081 Campinas SP Brazil Addendum: Sorry, something always slips out. I'm running 4.1.1 on all machines involved. When I said I didn't find a patch related to SCSI disks, I meant a patch for 4.1.1. ---------------------------------------------------------------------- Thanks to the following respondents: From: markw@utig.ig.utexas.edu (Mark Wiederspahn) From: birger@vest.sdata.no ( Birger Wathne) From: Larry Chin <larry@cch.com> (message truncated, unfortunately) From: poffen@sj.ate.slb.com (Russ Poffenberger) From: birger@vest.sdata.no ( Birger Wathne) -- Paulo Licio de Geus INTERNET:paulo@dcc.unicamp.br Depto de Ciencia da Computacao DCC - IMECC - UNICAMP caixa postal: 6065 13081 Campinas SP Brazil
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT