Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!rutgers!cbmvax!steveb From: steveb@cbmvax.UUCP (Steve Beats) Newsgroups: comp.sys.amiga Subject: Re: 2090A and DMA (was: Re: 2000-and-1 expansion box) Message-ID: <4912@cbmvax.UUCP> Date: 1 Oct 88 15:36:15 GMT References: <1925@vu-vlsi.Villanova.EDU> <7246@well.UUCP> <10313@s.ms.uky.edu> <12453@oberon.USC.EDU> Reply-To: steveb@cbmvax.UUCP (Steve Beats) Organization: Commodore Technology, West Chester, PA Lines: 31 In article kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > >Uh ... I really hope this is just an over generalization you've made, Marco, >and not true. I had thought the 54 Meg partition size limitation/bug was to >have gotten fixed in the 2090A. And also the number of heads limit, etc. > >CATS? > >/kim > The 54 Meg partition size limit is a bug in the filing system. That limit is present on ANY hard disk (or RAM disk) that has the old 1.2 Filing system mounted on it. Partition was the key word. The device doesn't handle partitions, the filing system does. This has been theoretically raised to 2.5 Gigabytes by the Fast Filing System in the V1.3 Workbench release. Now I have a question. How can we transparently handle disk media that has a capacity >2.5 Gigabytes. A lot of software is going to break just because they've gone over 31 bits of offset (a longword becomes negative then). An even larger problem exists when you go over 4.2 Gigabytes since that will overflow a longword. IO_OFFSET specified in blocks would have made sense (especially since everyone in the world says IO_OFFSET must be a multiple of the devices blocksize), but that's not an available option. The only safe thing I can think of are CMD_READ_EXTENDED and CMD_WRITE_EXT on future device drivers. It isn't possible to just limit partitions to <2.5 Gigs since the filing system has to make it's requests in terms of physical blocks, not blocks relative to the start of the partition. Anyone got any ideas they'd care to air ? Steve