*BSD News Article 2028


Return to BSD News archive

Path: sserve!manuel!munnari.oz.au!uunet!think.com!rpi!usc!news
From: merlin@neuro.usc.edu (merlin)
Newsgroups: comp.unix.bsd
Subject: Re: Corrupted files?
Date: 18 Jul 1992 14:48:08 -0700
Organization: University of Southern California, Los Angeles, CA
Lines: 73
Sender: merlin@neuro.usc.edu (merlin)
Message-ID: <l6h4coINNcp1@neuro.usc.edu>
References: <l6g5ggINNbo7@neuro.usc.edu>
NNTP-Posting-Host: neuro.usc.edu

In article <l6g5ggINNbo7@neuro.usc.edu> merlin@neuro.usc.edu (merlin) writes:
>I have tried ethernet transfer and floppy disk transfer of files for
>the binary distribution to my hard disk -- I keep getting file corrupt
>on bin01.44, bin01.49, bin01.54 -- I presume no one else has a similar
>problem -- but it has happened with files from wuarchive and files from
>gatekeeper.  I did all the transfers in binary mode.  I'm not at all
>certain what I might be doing wrong.

As it turns out the files on the servers are not corrupted.  I managed to
cat | zcat | cpio these files on my SUN 4/360 just fine.  However, when I
tried transfering the files to our 386DX-33/Maxtor8760E ESDI disk, these
files ended up on what appear to be bad sectors.  No amount of recopying
over these original files or deleting and restoring the contents of these
files did any good.  What did help was to simply rename the files bin01.nnx
-- and -- then to restore the files (in newly allocated disk space) from 
either floppy disk or the network.  This made extract happy with MANIFEST
checksums and allowed unpacking of the bsd binary distribution.

Now for what might be a trivial question.  There were no errors reported
anywhere for the writes/reads involving these files.  Moreover, the only
error reported was the 'corrupted' file message from extract.  Also, the
bootup sequence now reports one (and only one) bad sector #476915.  I ran
'bad144 wd0 0' from both hard disk and from the maintenance disk -- but it
seems as though the system just hangs.  Is there any way to ask 386bsd-0.1
to check the unix partition on an ESDI disk and maintain a correct listing
of bad tracks either before or after installation of the system?  'bad144
wd0' responds with what looks like a table of random supposed badtracks
most of which are outside of the range of possible tracks on a 676MB ESDI.

Why would the only errors reported come from extract verifying checksums?
Shouldn't there be some other filesystem error checking which would detect 
these data errors?  I'm not being critical here -- I'd just like to get a
better understanding about the reliability of the filesystem.  As far as
I'm concerned, if we can effectively badtrack the system, few enough novel
errors appear on my ESDI disk to worry about these reliability problems --
but for end user system delivery platform it would be nice to be somewhat
more able to reassure users their data will be maintained intact by error
detection and correction routines inherent in the filesystem.  Indeed, for
development purposes it would be nice to believe source code and binaries
are at least reliably maintained on disk.

All in all, so far I am very impressed with this system.  I haven't gotten
very far with development work on this platform -- but I'm getting pretty
close to at least be able to run the BRLCAD ray tracing benchmarks.  It may
be interesting for some people to be able to review some comparison of the 
performance of 386BSD vs SCO UNIX from the perspective of raw efficiency as
well as simplicity of porting software from the SUN OS environment.  The
BSDI386 people claimed their system made such ports relatively transparent.
Perhaps the same claim can be made for 386BSD.  BRLCAD will be a good test
-- it's several hundred thousand lines of C source code with extensive use
of many unix system facilities including network libraries.

Best, AJ

p.s.  Has anyone considered porting the u386mon program which allows real
time monitoring of system performance and use of system resources on the
current SCO UNIX 386 systems?  The software is shareware and really quite
helpfull for tuning what may be otherwise rather opaque kernel parameters.

------------------------------------------------------------------------------
Alexander-James Annala
Principal Investigator
Neuroscience Image Analysis Network
HEDCO Neuroscience Building, Fifth Floor
University of Southern California
University Park
Los Angeles, CA 90089-2520
------------------------------------------------------------------------------