Date: Thu, 4 Jan 1996 00:08:30 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, jkh@time.cdrom.com, freebsd-hackers@freebsd.org, obrien@cs.ucdavis.edu Subject: Re: X for install Message-ID: <199601031338.AAA07790@genesis.atrad.adelaide.edu.au> In-Reply-To: <1255.820673180@critter.tfs.com> from "Poul-Henning Kamp" at Jan 3, 96 01:46:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp stands accused of saying: > > There are a few "better" ways perhaps to look for more unique things, > > but you'll still be screwed by two identical disks with identical > > contents 8( > > Well my idea was something like: > > sector = 0 > while (1) > for all disks the bios knows about > read $sector > update checksum[disk] > if checksums differ > store checksum[] & $sector > sector++ Two 1G disks, one IDE, one SCSI. Both (miraculously) have identical MBR's, and no contents. (Think scrubbed disks) Or two identical recently-low-level-formatted disks on a single SCSI controller in the presence of ID hardwiring. Or even the same disks after they've been labelled and have identical filesystems on them. And how much of the disk are you going to read before you give up? (Yes, I know a better approach would be to scatter the reads exponentially across the disk) The problem is not the general case, it's the worst case. I guess the question is whether the worst case is worth worrying about... 8) > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601031338.AAA07790>