From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Haertel Message-Id: <200205260511.g4Q5BjDB093169@ducky.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in disk/format In-Reply-To: Date: Sat, 25 May 2002 22:11:45 -0700 Topicbox-Message-UUID: 9c883b4a-eaca-11e9-9e20-41e7f4b1d025 >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.