Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!apple!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: 16 meg partition limit Message-ID: <2020@atari.UUCP> Date: 5 Feb 90 19:17:11 GMT References: <2947@water.waterloo.edu> <1325@crash.cts.com> <20465@watdragon.waterloo.edu> <3&3+Y|@rpi.edu> Organization: Atari Corp., Sunnyvale CA Lines: 71 brazil@pawl.rpi.edu (Timothy E. Onders) writes: >In article <20465@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven W. Klassen) writes: >>mentioned the 16 meg limit, however, the utilities which came >>with it allowed me to make larger partitions. >Those would be HDX 3.0. HDX 3.0 allows partitions up to 1 GBy (that's >1024 MB in case you didn't know.), It also allows more partitions per >physical drive. Right. Actually it's 3.01; the driver that came with 3.0 had a bug, though the formatter (HDX) is the same. >>unreliable for long term use? Certainly not. >The only problem, however, is that many disk utility programs ... >don't know how to handle the larger partitions. Also right. Here's the bottom line: when you have a partition larger than 16MB, the driver creates the partition with 1KB sectors (or more!) rather than 512-byte sectors, which is the old value. Cluster size is still two sectors, whatever size that is. The disk itself is formatted with 512-byte sectors, and Rwabs does blocking and deblocking, turning requests for "one logical sector" into as many physical sectors as necessary. The reason for the large-sector implementation is that all GEMDOSes can handle any (power-of-two) sector size, but not all can handle a cluster size other than two. The drawback is that some (most) utilities assume that one sector is always 512 bytes. They could have used the Getbpb() call and used the sector size returned from that, but the original TOS documentation all but guaranteed 512 bytes forever. These programs will crash, or worse, will fail quietly because they read "one sector" into a buffer which is only 512 bytes long; the Rwabs transfers 1K, clobbering whatever came after the buffer in memory. Also, their notion of how big a sector is (e.g. number of directory entry slots in a directory sector) will be wrong. As an additional complication, if you use the "raw mode" (also called "physical device") bit in the first arg to Rwabs, you get physical sectors, which are still 512 bytes. That number is not obtainable as a variable anywhere, so it'll probably stay at 512. The hardest-hit class of programs is the "add cache sectors" or other disk-caching kind, because it needs to know how big a buffer to allocate. The answer to that question is impossible to compute, so it's available from the hard-disk driver. (It's impossible to compute because it involves a user-preference value which can be patched into the driver: with removable media you could pop the cartridge and put in one with larger logical sectors, so the user tells the driver a minimum for the "maximum sector-size" value to use.) CACHExxx.PRG from Atari, of course, interrogates the driver and uses that number correctly. I'm not publishing the way to interrogate the driver here because I would not get it right. The straight scoop is avaiable to developers in the HDX 3.0 Release Notes document. The moral is, utilities should always use Getbpb to find out how big sectors are, how many sectors per cluster, etc., and base all your other calculations and "constants" on the answers. If you're adding GEMDOS buffers or other permanent objects, get the release notes and do it right. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt