From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in disk/format From: rsc@plan9.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sun, 26 May 2002 00:13:13 -0400 Topicbox-Message-UUID: 9c7c6022-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. I found a different problem, though, which is fixed on sources. The amount of space required by the FATs depends on the number of bits per FAT entry, which depends on the number of FAT entries, which depends on the amount of disk space left over after subtracting out the space used by the FATs. Oh, and if you somehow divine the number of bits per FAT, the amount of space required by the FATs still depends on the number of FAT entries still depends on the number of clusters, which depends on the amount of disk space left over after subtracting out the space used by the FATs. Before we had an approximation that didn't work when you were close to the dividing line between 12-bit and 16-bit FAT entries (having an 8MB 9fat would put you close enough to cause problems). Now we just guess until we find a fixed point. This isn't your problem, though -- this bug makes reads fail much earlier than 55000 bytes into the file. Russ