Michael,
Is your HDD one of those "never will need a low level format" IDE/EIDE
drives? If so, you might want to check with the IBM website or get
feedback from "the guy what had the problem with the 1/2Gb HDD" for the
utility that will write all 0000 -- the equivalent of LLF for IDE.
However, in my case I doubt the lost chains can be laid on HDD surface
failure as the cause. I optimize routinely, which means files don't get
written and rewritten to the same sectors constantly; NDD doesn't even
hesitate as is purrs through "the logical drive which used to be known
as I: and now is J:"; until 1.50 s.r.c. Arachne was run from RAM drive
and only zipped file, batch files, mail, hotlist, history were kept on
HDD; I added disk caching shortly after moving Arachne to actual
operation on/from HDD; we're talking a Quantum SCSI which is supposedly
among the top 2-3 in quality and reliability [it certainly was in *cost*
when I got it].
If I was finding contaminated files that were supposed to be there
[rather than contaminated deleted files, or complete files that were
supposedly erased], or having failures in performance caused by
incomplete files, "cannot read," etc I would consider failure of medium
to quite possibly be at fault. I might even want to blame those chains
on the diskcaching program I was using -- if it weren't for the fact
that I have used both ncache and smartdrive with nearly duplicate
problems with lost chains. The only major difference I've seen in the
"lost chains problem" has been since I switched to 1.64 and suddenly
there are many more chains, which are much longer -- long enough to be
saved as complete files when concatenated by chkdsk.
I just ran NDD on the logical drives I: J:[Arachne] and K: No errors on
I: or K: but Lost Chain Cluster in J:\spider\smtp.log was found. This
matches up with the fact that many of the files created from lost chains
have been complete e-mail messages I've sent.
Note: I don't know if the culprit responsible for the jump in lost
chains is all of Arachne 1.64 or just smtp.log; I didn't run smtp.log
for any version prior to 1.61, and only within the last month ran
smtp.log with 1.61 and now 1.64. So there could have been a problem
before that never happened because I never used that portion of the
program.
The drive Arachne sits on is 241,857 sectors; sector size is 2048. So I
don't think it's a matter of little bits of stuff being lost in great
big sectors. After running NDD I ran SD, and 97% of the drive wasn't
fragmented, and only files were unfragmented -- a total work time of 4
seconds. So, as I've said before, I don't think its the HDD itself.
I just took a look at the file that NDD saved, and I find it very
confusing. The first section of the file is a complete message with
headers, plus the end of file period "." and the QUIT command sent to
the server. But then after that is another fragment of the same file,
bits and pieces... This was not a message I'd saved anywhere, like to
outbox, and then rewritten. This was a relatively short message I had
typed once and sent directly from the reply page. So how did bits and
pieces of the message get schmeared around? Maybe this is something
Michael might understand?
l.d.
====
Michael <xChaos> was heard to say:
> If you were runningg Archne for long time without using disk cache, your
> hard drive may became little bit "tired by permanent overlaying, and now
> it should be considered more or less unusable :-(
> This is warning for everyone, who is not using Arachne with RAM disk or
> disk cache !!!! It is recommended if you want to use your hard disk even
> in future....
--
Learn about B'FOR
Join B'FOR - B'mothers For Open Records
<a href="http://www.b-for.org">B'FOR www.b-for.org</a>
[Associate members of triad also welcome; membership confidential if desired.]
-- Arachne V1.64, NON-COMMERCIAL copy, http://arachne.cz/
