Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!NISC.SRI.COM!cwilson From: cwilson@NISC.SRI.COM (Chan Wilson) Newsgroups: comp.sys.apple Subject: Re: file system questions Message-ID: <13380@fs2.NISC.SRI.COM> Date: 20 Feb 90 12:40:05 GMT References: <@fs2.NISC.SRI.COM> <38782@apple.Apple.COM> Reply-To: cwilson@NISC.SRI.COM (Chan Wilson) Organization: Network Info Systems Ctr., SRI Intl., Menlo Park, CA. Lines: 38 In article <38782@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes: >In article<13373@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >>[...] >>Ever realize that HFS is limited to 32 MB volumes? Betcha you didn't >>know that. :) HFS gets around the limitation by using allocation >>blocks in conjunction with logical blocks to achieve the larger volume >>size. Catch is, there's a tradeoff. The larger the drive is, the >>larger the allocation blocks are. > >Considering that you've just explained HFS *isn't* limited to 32M volumes >(you're correct, it *isn't* limited), how did you manage to start out by >claiming it was? Oops, I figured someone would catch me on that. -) >If you're saying HFS is limited to 65536 allocation blocks, I'm willing >to believe that (I haven't tried to look it up). That's not the same >as being limited to 32M volumes. Yea, that's what I meant. >The ProDOS file system *is* limited to 32M volumes, because there is no >such allocation block scheme. (Trying to introduce one now would kill >all utilities that do block-level access, of course.) Speaking of such, would there happen to be a new filesystem definition in the works? Granted, HFS can access the larger volumes, but it does seem to have it's weak points. Is this why we haven't seen an HFS FST? >David A. Lyons, Apple Computer, Inc. | DAL Systems --Chan ................ Chan Wilson -- cwilson@nisc.sri.com radius!cwilson@apple.com Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu I don't speak for SRI, someone else does. ................