Thread View: comp.sys.next.software
4 messages
4 total messages
Started by Dmitri Linde
Mon, 10 Aug 1992 21:01
RAMDISK, not a joke!
Author: Dmitri Linde
Date: Mon, 10 Aug 1992 21:01
Date: Mon, 10 Aug 1992 21:01
54 lines
2237 bytes
2237 bytes
The ramdisk posting is not a joke. Many people have replied to me saying that ramdisk is useless, but some people suggested several uses. 1)Mount a floppy disk image (this is for those without floppy disk drives) 2)Put cc, ccp and headers and includes and libraries on the ramdisk. Also all object files should go to ramdisk when compiled. When developing a program, even the executables should reside on the ramdisk. 3)Put tex, latex, plain.fmt, latex.fmt, inputs, etc. onto the ramdisk. 4)mount another ramdisk as /tmp, since a lot of comilation takes place there. Putting it on the ramdisk is O.K. since /tmp gets erased at startup anyway. 5)shared files on a NFS file server should be on the ramdisk to improve the transfer time and decrease cpu load. I do have a few problems with ramdisk, and that is why I have not submitted it to nova.cc.purdue.edu yet. Something is wrong with filesystems. Read and Write routines work fine. I cat some text into er (name for the ramdisk driver special block file, should really be something like /dev/rramd0a). But when I mkfs on the ramdisk and mount it and try to look into the mounted dir, the NeXT panics and reboots. When I take a disk image off the floppy disk and load it into the ramdisk I also have problems. I type cat /dev/rfd0a>er mount er /RAMDISK cd /RAMDISK NeXT does not panic, and I can look at the filesystem, but things get confused: I can make new files and erase them prefectly well, but when I try to read files which were on the floppy disk, I get garbage (usually containing parts of the new files I made). Looks like inodes do not point to the right places. Any ideas? Should I give some more options to mkfs besides the size and the name? /etc/mkfs er 2048 ?? Thanks, - Dmitri Linde Please reply to dmitri@StarConn.com
Re: RAMDISK, not a joke!
Author: M Carling
Date: Mon, 10 Aug 1992 21:42
Date: Mon, 10 Aug 1992 21:42
14 lines
851 bytes
851 bytes
In article <9208102140.AA04340@physics> dmitri@physics.stanford.edu (Dmitri Linde) writes: > The ramdisk posting is not a joke. Many people have replied to me > saying that ramdisk is useless, but some people suggested > several uses. Why not just buy a solid-state SCSI disk with a 0.15 millisecond access time? M Carling Director, Bay Area NeXT Group -- Save a child, shoot a drug dealer. Save a thousand, shoot an abortionist.
Re: RAMDISK, not a joke!
Author: Andrew Loewenstern
Date: Tue, 11 Aug 1992 07:17
Date: Tue, 11 Aug 1992 07:17
30 lines
1787 bytes
1787 bytes
In article <1992Aug10.214244.20385@leland.Stanford.EDU> m@crito.Stanford.EDU (M Carling) writes:
>In article <9208102140.AA04340@physics> dmitri@physics.stanford.edu
>(Dmitri Linde) writes:
>> The ramdisk posting is not a joke. Many people have replied to me
>> saying that ramdisk is useless, but some people suggested
>> several uses.
>
>Why not just buy a solid-state SCSI disk with a 0.15 millisecond access
>time?
hmmmmmm, would those work? Those suckers are cool, but expensive....
It would be nice if NeXT would either beef up the cache allocation, or
make it settable via a file... It would be cool if Mach did what
NetWare does... NetWare uses ALL unused memory for file, FAT, and
TurboFAT caching. A 32-meg NetWare server just cranks, even with a
LOT of disk access going on. So if Mach turned all available memory
into disk-cache and then released it as memory was needed (until the
disk cache reaches a certain point), we'd prabably get more speed.
But Chris Lloyd is right... the SCSI drivers (and many more low-level
drivers) seem to be pretty screwed up.
andrew
--
andrew@cubetech.com | "We shall not cease from exploration
Andrew Loewenstern | And the end of our exploring
Cube Technologies, Inc. | Will be to arrive where we started
| And know the place for the first time." -T.S. Eliot
Re: RAMDISK, not a joke!
Author: Marcel Weiher
Date: Tue, 11 Aug 1992 16:35
Date: Tue, 11 Aug 1992 16:35
31 lines
1968 bytes
1968 bytes
andrew@cubetech.com (Andrew Loewenstern) writes: [...] >It would be nice if NeXT would either beef up the cache allocation, or >make it settable via a file... It would be cool if Mach did what >NetWare does... NetWare uses ALL unused memory for file, FAT, and >TurboFAT caching. A 32-meg NetWare server just cranks, even with a >LOT of disk access going on. So if Mach turned all available memory >into disk-cache and then released it as memory was needed (until the >disk cache reaches a certain point), we'd prabably get more speed. But Andrew, it DOES! Mach keeps pages of files resident after they've been read (not just executable). Check out the "filemem" command, it tells you what pages of a given file are resident. It doesn't have a manpage. I came across this when wanted to test disk throughput with a 10-20MB file (to swamp small buffering schemes). Second time around was several times faster, and it couldn't have been those puny buffers the kernel tells us about at boot-up. Coming to think of it, what ARE those buffers anyway? >But Chris Lloyd is right... the SCSI drivers (and many more low-level >drivers) seem to be pretty screwed up. Yeah, 700K max. throughput on those fast 520Meg Fujitsus is ridiculous. So is < 1 MB/sec on a 3.5" Gigabyte drive that can do 1.2 MB/sec physical (from the platter, or so I'm told) and something like 4 + MB in burst mode. >andrew Marcel
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads