The original query is set out here because it was posed so long ago. It
has taken until now to resolve the problem. It manifested itself by the
news gathering process dropping from 280,000 articles per day to
90,000 with the new Quantum being the main news spool (there are two others).
Original text ::
We sent a mail to Quantum support asking how we tweaked
their 4.3gb Atlas drives so they could be used in an Alpha
Storageworks cabinet and received the following, rather
unhelpful, reply.
From: qsupport_at_qntm.com (Quantum Support)
Subject: Re: details on how to tweak an Atlas for use in DEC Storagew
The question you have is better directed at Digital. We do not
provide consultation on drive configurations on an OEM product like
the Alpha. DEC can provide what attributes, if any, are needed to
provide better or enhanced performance. If anything needs to be
changed in the drive you would need to get a SCSI editing tool and
modify the mode page parameters in the device, this is something we do
not provide.
Digital say, Ask Quantum. I thought we were over this
problem of chasing your tail but I think Quantum are more
at fault if they want to sell as many drives as possible
then they should do all they can to make them compatible.
Does anybody know what attributes should be tweaked and how
we obtain a SCSI editing tool to do it. We DO have a working Quantum in
the cabinet which was modified by a distributor but the dist. is no
longer available to ask. However, perhaps a suitable tool could read the
parameters off the disk???
Thanks to all those who helped resolve this query. The initial replies
were in two parts, philosophical concerning who to buy drives off, and
technical into observations on how to edit mode pages.
Most contributors on the first point felt that you needed the support of
DEC in order to avoid this sort of problem ie buy from DEC because DEC
would buy large quantities from whoever and the disk manufacturer would
obviously support the large purchaser rather than us buying a few
drives. The problem with this may be limited to this side of the
Atlantic but DEC prices are nearly twice those of third party drives so
is the difference worth it? In this case almost certainly yes but in
general????? Also note the actual cause of the problem below.
THe scsi editing tool is scu and comes as part of DUNIX. It is easy to
use and is well documented and has built in help of the VMS type ie
topic, sub topic etc. I used it to produce mode page printouts for both
the working Quantum drive and the new drive which was causing the problem
and mailed it to those who had covered the technical side of my query to
see if they could possibly spot where the problem might lie.
Unfortunately nobody could.
We continued testing and trying to gather data about the problem and also
managed to get a European Quantum engineer on board who was interested
in what was happening. DEC also were involved thru the UK response
center when it became apparent that it was not the drive itself that was
at fault but either DUNIX or the interaction of DUNIX and the drive
parameters.
As the lousy thruput we were experiencing was associated with one
application - INN - we
narrowed the problem down by analysing what was happening in INN, in the
expire process, in the fastrm program, in the unlinking of individual
files and eventually came to realise that the system was taking 5 seconds
(yes I mean five seconds) to rm a file. It was creating them fast enough
but not eliminating them. Closer still and we found it was only one
directory where this was happening. In INN you have a junk directory
where you file stream fed articles you dont want. Typically you have a
cron job run round once an hour and fastrm the buildup. This job had
failed and the initial buildup was to 200,000 unwanted files,
subsequently reduced by brute force to half this number. Apparently the
pointers in this directory were screwed but still consistent and passed
fsck tests. No other directory was affected.
The solution was easy. The news was paused, junk was moved to junk.old ,
junk was recreated and the news restarted. We then occupied nearly four
days fastrming the remaining 100,000 files off the system so we could
kill the junk.old directory.
Peace now reigns. Whose fault? Dont know. But if you get similar
performance problems I strongly suggest you investigate whether there are
any very large directories involved.
Stuart McKenzie
Received on Mon Jun 09 1997 - 18:13:44 NZST