Re: [Fwd: Re: [cobalt-users] THE GRINDING DRIVE PROBLEM]

[Jeremy Anthony Kinsey <webmaster@xxxxxxx>]

Will DeHaan said:

>As sent to cobalt-users@xxxxxxxxxxxxxxxx
>
>Please respond promptly to the list only so that I may assist you this
>morning.

no problem.
>
>
>Jeremy,
>
>Interesting problem, but it's presented to the list a little
>simplistically.  Most hard drives make a high pitched screaming noise,
>yes, much like attending an Indy race, when they are failing.  

With over 60 colo servers on our network we have learned over the years 
what a failing drive will do.  We have also seen/heard the same exact 
noise from a RaQ when it is dyeing.. 
>
>I don't know what you mean by "grinding" however.  A server that does
>not have enough memory will start swapping, the hard drive will start
>chugging away, server performance will decrease rapidly, and if not
>fixed in a few weeks or months time the hard drive will fail.  As
>expected.  Get an OS restore CD, buy any brand hard drive, add it to a
>server that does not have enough memory, and watch the drive fail as
>expected. 

What I mean by "Grinding" is that this is the description that Cobalt 
gave us when referring to this problem.  Cobalt told us of a "Grinding 
Drive Problem" (I quote it, because this is how it was stated by Cobalt). 
 

We have an OS restore CD and have used it on several occasions.. I would 
like to try your experiment, but I do not have time for that.  The memory 
issue has me a bit confused.. This box has 80MB of RAM.  
>
>Jeremy, could you telnet to a RaQ that is making this grinding noise and
>type the following, then send output back to this list?
>
>cat /etc/build
>cat /proc/meminfo
>w
>df

[admin admin]$ df
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda1             495682  250305   245377     50%   /
/dev/hda3             198275   15915   182360      8%   /var
/dev/hda4            3249383 1632845  1616538     50%   /home



[admin admin]$ cat /etc/build
build 2.561 for a 2800R in English


[admin admin]$ cat /proc/meminfo
        total:    used:    free:  shared: buffers:  cached:
Mem:  81465344 71847936  9617408 390254592  1691648 25587712
Swap: 133885952  3452928 130433024
MemTotal:     79556 kB
MemFree:       9392 kB
MemShared:   381108 kB
Buffers:       1652 kB
Cached:       24988 kB
SwapTotal:   130748 kB
SwapFree:    127376 kB

>
>Please be patient as I don't think the problems you're experiencing are
>common problems to other Cobalt users.  

That's why I am asking.. Are we just an isolated incident?  I don't think 
so, especially since Cobalt told us directly that this "Grinding Drive" 
was an issue, mainly in the Qube.
>
>You will make the nice technical support guys take offense by implying
>that they haven't been honest with you when no doubt they haven't been
>able to obtain a reasonable set of symptoms about your problem(s).  Why
>do you double quote "The Grinding Drive Problem"?  A search of
>cobalt-users from its inception does not turn up this phrase so I don't
>see how you could expect other Cobalt users to be familiar with this
>problem.
>

I am not trying to be offensive to anyone, nor am I implying anything.  I 
have merely repeated a statement made to me by Cobalt, about a "Grinding 
Drive" problem occurring in the Qube, and the RaQ1.  I am not saying 
there is a lack of honesty, perhaps more of a lack of communication.  The 
problem does exist however, and we have confirmed it on several 
occasions. Surely there must be a record of our past RMA's and Spare in 
the Air shipments?  Each time we have noted the "Grinding Drive" problem. 
 The reason the Cobalt-Users list archive does not turn this up, is 
number one we have not posted on this issue more than twice, and two, the 
list is moderated.  Not all of our posts make it through.

Again, I am not being offensive, nor am I implying anything.  Service has 
always been great, the units have serviced our customers well, and 
getting the replacements has been nothing but timely ever time!  We just 
need to know that the "Grinding Drive" problem is being looked into, and 
that we are not the only ones?  If the "memory" issue is the problem, I 
will be the first to admit it.  

Regards,
Jeremy Anthony Kinsey
VP Network Operations

_______________________________________________________________________
www.bella-mia.com                     Maria's Internet Access
                                            www.mia.net
                                           www.dslone.com
Bella Mia, Inc.                           
401 Host Drive                        e-mail: jer@xxxxxxx
Lake Geneva, WI. 53147       Phone:(262)248-6759  Fax:(262)248-6959   
USA                                    Pager:(414)515-1388         
________________________________________________________________________
 National Internet Access, DSL and Colocation 375+ numbers and growing!
                       http://www.hostdrive.com