Re: [9fans] bug in disk/format

[rsc@plan9.bell-labs.com]

> Here is the md5 checksum of my /bin/disk/format binary: hopefully it
> will be identical to what was on sources before your fix.  (Is there
> a dump filesystem on sources that the rest of us can look at?)

Sources is a kfs, but I do have dump CDs.  I'll see if I can
make them available on a separate tcp port.

> term% md5sum /bin/disk/format
> 73e3a9480e3c973097e95dfcfd015a85	/bin/disk/format

That's correct.

> Finally, just to rule out the possibility of a corrupt executable
> text cache on my machine, I copied /bin/disk/format to /tmp/format
> and ran the same example again using /tmp/format, with the same
> result.
>
> By the way, in your attempt to reproduce this problem did you use
> a system with a SCSI disk?  Note that the behavior of opendisk()

No, just a zeroed file appropriately sized.
I don't think format actually cares about
the geometry.  I don't have any SCSI disks handy.

> is different for IDE vs. SCSI disks, particularly how it guesses
> the disk geometry.  In the past I submitted a bugfix to disk.c that
> would greatly increase the likelihood of SCSI geometry being correctly
> guessed, and I see my patch was ignored...

More likely just missed.  Where is this patch?

> In fact, disk/format guessed the wrong geometry for my SCSI disk:
> the BIOS geometry is 255 heads and 63 sectors per track.  But even
> if disk/format assumes the wrong geometry when it creates a DOS
> filesystem, dossrv should work just fine since dossrv uses linear
> addressing and so doesn't know or care about c/h/s geometry.

Right.