Re: [9fans] bug in disk/format

[Mike Haertel <mike@ducky.net>]

>I can't reproduce your problem.
>
>Was this the first 9fat ever present on the disk?
>Was there an earlier 9fat that you had mounted
>before running the format and the remount?
>
>The only thing I can think of is that you had run
>9fat: earlier, so dossrv had the FATs in its
>buffer cache.  When you reformatted, dossrv kept
>using the old FATs, hence the breakage of
>files on sector boundaries.

Nope, I had already thought of that.  Watch this:

# take care to make sure there is no stale data in dossrv
term% kill dossrv | rc

# zero out the 9fat partition
term% dd -if /dev/zero -of '#S/sd01/9fat' -count 1
1+0 records in
1+0 records out
term% dd -if /dev/zero -of '#S/sd01/9fat' -seek 2
write: i/o error
20481+0 records in
20481+0 records out

# prove the 9fat partition contains nothing but the Plan 9 partition table
term% cat '#S/sd01/9fat'
part 9fat 0 20482
part fs 20482 16971204
part swap 16971204 17912412

# format the 9fat partition and install 9load et al.
# n.b. this is the same version of disk/format as my previous email.
term% disk/format -b /386/pbs -d -r 2 '#S/sd01/9fat' /386/9load /386/9pcdisk /tmp/plan9.ini
Initialising FAT file system
type hard, 10 tracks, 64 heads, 32 sectors/track, 512 bytes/sec
Adding file /386/9load, length 177320
Adding file /386/9pcdisk, length 1744105
Adding file /tmp/plan9.ini, length 185
used 1927168 bytes

# start up a fresh dossrv and look at the 9fat partition.
term% dossrv
dossrv: serving #s/dos
term% mount /srv/dos /n/9fat '#S/sd01/9fat'
term% cmp /n/9fat/9load /386/9load
term% cmp /n/9fat/9pcdisk /386/9pcdisk
/n/9fat/9pcdisk /386/9pcdisk differ: char 169985

But: Hmm, that's very interesting.  This time there is no cmp error
in 9load, but 9pcdisk still got copied incorrectly.  The error is at
a different offset than last time.

Just for good measure I tried the exact same sequence of commands
again, and got the exact same result: a cmp difference in 9pcdisk at
offset 169985.

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

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

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()
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...

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.