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 ------------------------------------------------------------------------------