Date: Mon, 25 Oct 2004 22:19:17 -0400 From: "Matt Emmerton" <matt@gsicomp.on.ca> To: "John Von Essen" <john@essenz.com>, "Doug Russell" <drussell@saturn-tech.com> Cc: freebsd-hackers@freebsd.org Subject: Re: hacking SCO.... Message-ID: <001f01c4bb02$39602ef0$1200a8c0@gsicomp.on.ca> References: <20041009044403.P39589-100000@mxb.saturn-tech.com> <76A94E35-26E8-11D9-839A-0003933DDCFA@essenz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This may be a dumb question, but if you make a cpio tape archive from > data on an SCO system (HTFS filesystem), you can still restore the data > off the tape to another system, like FreeBSD with a UFS filesystem, > right? This should work. If you run into any issues they will be incompatibilities between SCO's cpio and the GNU cpio that FreeBSD uses. > And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am > going to try and convert these people from their SCO box over to a > FreeBSD system. Just want to make sure the data will come off the tape. Yes, but support is really limited. You need to copy a bunch of core libraries onto the FreeBSD machine from the SCO machine to make things work. (We just emulate the syscall interface -- you need libc and friends from SCO.) Matt > > -John > > On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: > > > > > On Fri, 8 Oct 2004, Sergey Babkin wrote: > > > >> Try to use the "Verify" menu from the Adaptec BIOS. It finds and tries > >> to re-map the bad sectors (it tries to preserve data during this too, > >> unless the sector is completely unreadable). > > > > The verify commands issued by the BIOS are virtually useless compared > > to > > the type of tests done my sformat. If you enable automatic read > > re-allocation, it is almost the same as simply reading your whole disk > > with dd. > > > >>> I do the full 14 pattern tests before I put a SCSI disk in service. > >> > >> When a disk starts losing blocks like this, usually they only multiply > >> over time. The best thing you can do is replace the disk and > >> move the data before you lost more of it. > > > > NO! Not necessarily! > > > > If a disk has simply grown a few new defects since it was new, it does > > not > > necessarily mean it is going to die. I have many disks that had minor > > bad > > spots on them that weren't even always found by the factory format > > routines, or had appeared since (due to transport, debris in the HDA, > > poor > > holding power for the magnetic fields in some area, etc). If the drive > > passes through a few full patern tests without problems and doesn't > > continue to grow new defects, it is likely just fine. > > > > I've got all kinds of old SCSI disks that were 'discarded' due to > > errors. > > Only a couple are truly dead... the rest have been running for years > > with > > no problems after making a real grown defect list from the pattern > > tests. > > > > This is something I learned many many years ago when running my old > > Miniscribe 3650s on a Perstor high density controller. It formated the > > drives to 31 sectors per track instead of 17. Hard on the disks, and > > the > > media, but a good drive, after being properly tested, would run > > flawlessly > > for years being hammered 24/7 on BBS machines. Got 78 megs per drive > > instead of 42.whatever it was. :) > > > > Later...... <Doug> > > > > > > > John Von Essen (john@essenz.com) > President, Essenz Consulting (www.essenz.com) > Phone: (800) 248-1736 > Fax: (800) 852-3387 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001f01c4bb02$39602ef0$1200a8c0>