jabernathy@pro-houston.cts.com (Joe Abernathy) (11/12/89)
In-Reply-To: message from dkl@pro-houston.cts.com DKL writes: > I really need a way to beat the 32 MB limit myself - any way at all. I haven't heard of anyone beating it, but you might be able to work around it. Applied Engineering ships modified system software with its Vulcan 100 which allows you to access more than 2 devices in one slot. I'm using it now to support four volumes in slot 7, and can't think of any reason why their system software shouldn't run on a non-AE drive, if they'll let it out. Might be worth a call to Dallas. UUCP: crash!pro-houston!jabernathy ARPA: crash!pro-houston!jabernathy@nosc.mil INET: jabernathy@pro-houston.cts.com
ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) (11/18/89)
In-Reply-To: message from jabernathy@pro-houston.cts.com One method might be to increase the block size to 1k bytes (4 sectors) since Prodos is a block structured OS (right jargon?) this should double the effective size to 64Meg. The volume bit map just tracks blocks, not sectors, I think. This will increase wastage if you have a lot of small files, but you did ask for ANY solution.
mattd@Apple.COM (Matt Deatherage) (11/22/89)
In article <7484.infoapple.net@pro-generic> ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes: > >One method might be to increase the block size to 1k bytes (4 sectors) since >Prodos is a block structured OS (right jargon?) this should double the >effective size to 64Meg. The volume bit map just tracks blocks, not sectors, I >think. This will increase wastage if you have a lot of small files, but you >did ask for ANY solution. Yes, but this would also break any application that uses READ_BLOCK or WRITE_BLOCK, as well as requiring changes to the basic ProDOS command structure (since a file with the same number of blocks is now capable of having more data in it). In other words, it would probably break about 55% of the existing ProDOS 8 programs available today. -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
dkl@pro-houston.cts.com (David Karl Leikam) (11/23/89)
In CS-ID: #3008.cortland/info-apple@pro-houston mattd@apple.com (Matt deatherage) writes, > In article <7484.infoapple.net@pro-generic> ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes: >> >> One method might be to increase the block size to 1k bytes (4 sectors) since >> Prodos is a block structured OS (right jargon?) this should double the >> effective size to 64Meg. The volume bit map just tracks blocks, not sectors, I >> think. This will increase wastage if you have a lot of small files, but you >> did ask for ANY solution. > > Yes, but this would also break any application that uses READ_BLOCK or > WRITE_BLOCK, as well as requiring changes to the basic ProDOS command > structure (since a file with the same number of blocks is now capable of > having more data in it). In other words, it would probably break about 55% > of the existing ProDOS 8 programs available today. Waitasec. Guys, stop mme when I'm wrong, but _this doesn't gain you much_. Files still get allocated in blocks, and a 1 block file is still a 1 block file, regardless of block size. If a file doesn't need a whole block, too bad. This wastage is tolerable at the current blocksize, but not at the expanded size. About the only way to get around that wastage is to build your own translator, so to speak, to rationalize the files on the fly while writing to the new disk structure - a thing I suspect you'd have to do anyway. Otherwise, your seedling files are simply gonna waste 4 times as much room, and only quite large files are going to realize much benefit from this approach, in terms of saved space. Not so? > UUCP: crash!pro-houston!dkl ARPA: crash!pro-houston!dkl@nosc.mil INET: dkl@pro-houston.cts.com
blochowi@rt4.cs.wisc.edu (Jason Blochowiak) (11/23/89)
In article <7484.infoapple.net@pro-generic> ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes: >In-Reply-To: message from jabernathy@pro-houston.cts.com >One method might be to increase the block size to 1k bytes (4 sectors) since >Prodos is a block structured OS (right jargon?) this should double the >effective size to 64Meg. The volume bit map just tracks blocks, not sectors, I >think. This will increase wastage if you have a lot of small files, but you >did ask for ANY solution. If that were workable, it would indeed expand the max volume size to 64Mb. However, every ProDOS 8 application (not to mention ProDOS 8 itself) expects the blocks to be 512 bytes, and therefore sets up buffers, etc., for block access as 512 byte chunks. The obvious solution would then be to only run programs that don't do block-level access (most programs only do file-level access). Well, that still wouldn't quite work out, as when you open a file under P8, you have to give it a buffer, which (if memory serves) is 1k in size. This buffer is used for block i/o, and I would imagine that one half is used for data blocks, and the other is used for index blocks. In any case, if you doubled the block size, you'd have to double the i/o buffer space, which means that you'd have to change all the applications... This would probably not be acceptable to anyone who's not a masochist. Btw, you are correct that the volume bit map deals with blocks, not sectors. The mapping of blocks to whatever unit is appropriate for the device in question (sectors, in the case of 5.25" disks) is the responsibility of a device driver. -- Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp "Education, like neurosis, begins at home." - Milton R. Sapirstein