9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: [9fans] [OT] heat-stroken disk? (was fossil/venti: diskReadRaw failed)
Date: Thu, 20 Mar 2003 00:07:56 +0100	[thread overview]
Message-ID: <200303192307.h2JN7u305651@zamenhof.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Wed, 19 Mar 2003 16:12:46 -0500." <6e2594b6d7f0bd77f330740aa143cf09@plan9.bell-labs.com>

> go buy a new disk.

Hmmm... getting off-topic... and long-winded...
the short summary is: watch out, don't overheat your disks...


The disk is a new (half-years old) maxtor 7200 rpm 80Gb disk,
never used much until now.

Similar disks were offered for a reduced price a while
ago at the local student computer shop at the campus.
I remember that a colleague who bought a disk then
mentioned people who came back to the shop with problems,
where the problems seemed to be due to overheated disks.

So far, the computer my disk is in has seldom been
on for more than a couple of hours at a time.
Now it has been on for more than 24 hours at a time,
with more or less constant disk usage/activity -
it contains the fossil and venti partitions.
Can overheating be the problem?

I just opened the computer case, and noticed that
the disk is, actually, not really in any airflow whatsoever
(in addition to being on and used longer than ever before).

I switched dma and rwm on again. A first time
(while repeating the 'cp .../fossil /dev/null' experiment)
this gave me some (kernel?) message about dma printed to
the console, and the machine (or at least rio, when
changing active windows) seemed to be slowed down
quite a bit. the dmactl and rwmctl fields in the output
of cat /dev/sdD1/ctl were reset to 0.

After a while I retried switching dma/rwm on, and it
stayed on.  I repeated the 'cp /dev/sdD1/fossil /dev/null'
experiment a couple of times.
After a few failures as before, it succeeded!
First time it succeeded, about half-way stats
showed a brief but almost complete drop in context,
syscalls and interrupts. After the first success,
repeated experiments (just a handful, and then 10+10 more)
were all successfull.
I also just gave another 'snap -a' and the first blocks
seem to have been written o.k. (for what it's worth),
if that's what the disk: io=10000 at ... lines tell me.

So, what does this give me?
A disk I fear to really trust?
a reason to reconsider the location of
components and the airflow in the case?
a reason to buy an additional fan, just to be sure?

The funny (ahem) thing is that when I just had opened
the case, indeed,  the disk was warmer than it is now,
but still, that temperature is in no way comparable to
the much higher temperature of the scsi disks I use for
the fs at the office: those scsi disks are in their own
disk cabinet, and even there they heat up enough to bake
an egg on -- or so it seems, but they seem to be able to
stand that (have not given problems, and they have been
on constantly for the last 2 years).


Oh well, and then I still have to redo the experiment
with increasing the amount of RAM in a laptop,
to report the complete error message I get from aux/vga
after the increase ('not enough free address space').
With the original memory (32Mb) I did not get the error,
with 80Mb (and no changes made, apart from changing the ram)
I do get the error. I searched the archive and found a few
hits, but I was not able to figure out how to solve
the problem from them.
As I started to say, I'll redo the experiment and
write down the exact error messages -- maybe tomorrow.

Axel.


  reply	other threads:[~2003-03-19 23:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-19 20:34 [9fans] fossil/venti: diskReadRaw failed Axel Belinfante
2003-03-19 20:39 ` Russ Cox
2003-03-19 20:52   ` Axel Belinfante
2003-03-19 21:01     ` Axel Belinfante
2003-03-19 21:12       ` Russ Cox
2003-03-19 23:07         ` Axel Belinfante [this message]
2003-03-19 21:01     ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303192307.h2JN7u305651@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).