jom@belltec.UUCP (Jerry Merlaine) (01/15/89)
With a RAM disk, you can't re-use the RAM for something else when the file system (database or whatnot) is not using it. With a RAM file system, however, you can allocate RAM when the user wants to store data and throw it away when the user removes files. Building a special-purpose RAM disk with a disk controller interface is a classic case of hardware people not talking to software people but instead going off and building something cute but useless. I would share the slow storage between a RAM filesystem, which would get first priority. Second priority would be local buffer caching for NFS or RFS clients. Third priority would be local disk buffer caching. Jerry O. Merlaine pacbell.com!belltec!jom
king@client2.dciem.dnd.ca (Stephen King) (01/16/89)
In article <334@belltec.UUCP> jom@belltec.UUCP (Jerry Merlaine) writes: >With a RAM disk, you can't re-use the RAM for something else when the >file system (database or whatnot) is not using it. >With a RAM file system, however, you can allocate RAM when the user >wants to store data and throw it away when the user removes files. Not in the Amiga. The RAM disc software that comes with the machine supports a dynamically resizeable disc. Write to it, and the capacity gets bigger. Delete a file and the disc shrinks. It is volatile storage, and always appears full, but it works. -- {utzoo|mnetor}!dciem!zorac!dretor!king or king%dretor@zorac.dciem.dnd.ca Stephen J King =-= DCIEM Human Factors Division =-= (416) 635-2149
dwc@homxc.ATT.COM (Malaclypse the Elder) (01/17/89)
In article <334@belltec.UUCP>, jom@belltec.UUCP (Jerry Merlaine) writes: > > Building a special-purpose RAM disk with a disk controller interface > is a classic case of hardware people not talking to software people > but instead going off and building something cute but useless. > ah but the disk controller interface is well defined and typicall represent the greatest common denominator for many systems. filesystem interfaces are less standardized. danny chen att!homxc!dwc
rcd@ico.ISC.COM (Dick Dunn) (01/17/89)
In article <334@belltec.UUCP>, jom@belltec.UUCP (Jerry Merlaine) writes: . . . > Building a special-purpose RAM disk with a disk controller interface > is a classic case of hardware people not talking to software people > but instead going off and building something cute but useless. Not at all true, especially in the case of the SSD for large IBM mainframes (an example that I gave). In that case, using a disk interface means that you can use the software as it stands, which makes it a useful product. In that world, you can't just invent another layer in the storage hierarchy... and unless you want to get very deeply into the software business, you don't go mucking about with VM and/or MVS. This is not to say that the software SHOULD BE harder to change than the hardware, but only that it IS for some classes of machine. There's also a consideration that when you're building huge bulk RAM devices, you may not want to make it behave completely like RAM. It may take more logic and more high-bandwidth stuff than to make it act as some sort of block-serial device. Remember, you're already talking about treating it as a second level of storage. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...A friend of the devil is a friend of mine.
snoopy@sopwith.UUCP (Snoopy) (01/18/89)
In article <334@belltec.UUCP> jom@belltec.UUCP (Jerry Merlaine) writes: |With a RAM disk, you can't re-use the RAM for something else when the |file system (database or whatnot) is not using it. |With a RAM file system, however, you can allocate RAM when the user |wants to store data and throw it away when the user removes files. | |Building a special-purpose RAM disk with a disk controller interface |is a classic case of hardware people not talking to software people |but instead going off and building something cute but useless. | |I would share the slow storage between a RAM filesystem, which would get |first priority. Second priority would be local buffer caching for |NFS or RFS clients. Third priority would be local disk buffer caching. Jerry, Jerry, Jerry. First you point out the error in dedicating a resource to one use, then you procede to do just that. (Okay, three uses instead of one, but still the same theme.) What you want to do, is to set things up so that all resources are maximally sharable. Example one: a Sequent style multiprocessor, rather than than having a master-slave, or dedicated IOP, or foobar accelerator. You don't run into the problem of part of the system being a bottleneck while another is loafing. Example two: the Mach OS use of the regular filesystem for paging space, rather than dedicating one or more disk partitions to swap. The same principle should apply to low-cost slow RAM. Use it as just another level of caching: registers on-chip cache (e.g. ns32532) off-chip cache main memory wafer RAM disk cache disk tape The question is, do teach the OS to handle another layer? Hook it in as a disk block cache which is transparent to the software? Redefine the layers, calling the wafer RAM "main memory", and wire what used to be main memory as a cache, and have a fast cache for the cache: registers on-chip cache off-chip fast cache off-chip slow cache (was main memory) main memory (wafer RAM) disk tape This last method is appealing. Of course this limits the size of the wafer RAM to the addressing space, typically 2-4GB these days. High end systems might want more. _____ /_____\ Snoopy (squeaking by nicely on a mere 3MB) /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy
mo@prisma (01/25/89)
Sorry, non-volatile (e.g., battery-backedup) ram caches are not obsolete. Read the Sprite filesystem papers from Berkeley. -Mike
daveh@cbmvax.UUCP (Dave Haynie) (01/27/89)
in article <1374@client2.dciem.dnd.ca>, king@client2.dciem.dnd.ca (Stephen King) says: > In article <334@belltec.UUCP> jom@belltec.UUCP (Jerry Merlaine) writes: >>With a RAM disk, you can't re-use the RAM for something else when the >>file system (database or whatnot) is not using it. >>With a RAM file system, however, you can allocate RAM when the user >>wants to store data and throw it away when the user removes files. > Not in the Amiga. The RAM disc software that comes with the machine > supports a dynamically resizeable disc. Write to it, and the capacity gets > bigger. Delete a file and the disc shrinks. It is volatile storage, and > always appears full, but it works. The Amiga's main ram disk, RAM:, is in fact based on a file system. The newer, recoverable ram disk, usually mounted as RAD:, is based on a device driver. But one really has to ask, "how do you define a RAM disk" vs. "how do you define a RAM filesystem". Certainly on the Amiga, most existing RAM based devices are based on just plain general memory, no special custom hardware or anything. In that system, such a device can always grow dynamically, but a RAM disk implemented at the device driver level can't safely shrink, while one at the filesystem level can. On other systems, you may define things differently. I suspect the original posting was talking about custom boards designed to give you a RAM disk, versus software that lets you use system memory as a filing system device of some sort. The results being, in the latter case, you're just running software, while in the former case, you have this special hardware that can't be used to directly run programs. > Stephen J King =-= DCIEM Human Factors Division =-= (416) 635-2149 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession