RAM Disks in Linux???

David Cole metalgrow at cds1.net
Fri Jul 9 16:17:36 PDT 1999


Thanks Devin,
    I only have 20seconds to do this message today,   but I realy need
to say thanks,  I hadn't thoght of dust in the CD (I'm going to find a
wall to bang my head against :)  I soold have thought of that)
    I hope to ask you some questions later,  I'll probably find a place
to plug in my laptop on sunday.
    THANKS AGAIN
           David Cole

Devin Carraway wrote:
> 
> On Thu, Jul 08, 1999 at 08:13:49PM -0700, David Cole wrote:
> >   My question comes from two directions,  and if the kernal and
> > all the daimeons use the swap only on ram overflow then one of
> > my reasons is dead.
> 
>         It's not strictly speaking done only on overflow -- the decision to
> use swap is largely mathematical, concerning how much memory you have vs.
> how much you've used.  Sleeping processes will get sent to swap when the
> kernel judges that their physical RAM could be used better for other stuff,
> typically either other processes or cache.  In general cache will displace
> processes that have been sleeping for a long time, assuming you run enough
> I/O through the cache over time.
> 
> > But my main reason is:
> 
> >   I want to eventually build a diskless Web server out of this
> > PII 400 128Mb.  With it serving its data from a 20Mb ram disk.
> > Booted and Loaded from a CD.
> 
>         So long as you tune the thing to be sure it stays under 108MB RAM in
> cache+process core, sure, you can run it swapless.  Configure your httpd to
> limit its resource usage (max processes, low max requests, etc.), don't
> enable things you don't need, and beat the machine up during testing to find
> out whether it exceeds its memory limits under heavy load.
> 
>         You might find that a CD isn't an especially reliable medium,
> especially over time -- or rather, that CDROM drives aren't especially
> reliable.  Time and dust tend to give them trouble -- usually quite fixable
> by whacking them, but if your intention is unattended massive reliability,
> you might look into a ~64MB readonly flash disk or some such.  If you intend
> to log what goes on on these machines, you'll need to log through the
> network; not a big deal, really, but a lot of stuff will expect to have a
> writeable log dir someplace.
> 
> > 1) I'm trying to design a server that when I reboot it or it's
> > watch dog timer reboots it,  it gets a fresh copy from a CD which
> > is year to year much more data relyable than a HD.
> 
>         Yeah, year-to-year you'd likely see problems with the CD drive.  The
> things just aren't made for that sort of thing.  Though an old NEC caddy
> unit might be worth trying; boot it a few hundred times while spraying it
> with dirt and kicking it periodically periodically; if it survives, send it.
> 
> > per day that goes corrupt after a week...reboot it and it's fine for
> > another week.  I was guessing the HD swap area has bad bits that
> > slowly gives Linux "kernel panic" Or a random speckled colored
> > screen saver and lock up, where there wasn't a screen saver.  I have
> > reasons to suspect the HD, but if what you say is true how could the
> > HD corrupt the kernel in a standard RH 5.2 Server install???
> 
>         The HD won't, but a failing HD with bad blocks in the swap area will
> feed random crap into the kmem, and that can make a big mess.  You can try
> turning off screen blanking on a tty left watching the kernel log, and see
> if it dies with useful errors on there.  Or grab a new HD and see if the
> problem repeats -- that bad it's almost certainly in hardware, either bad
> RAM or bad disk.
> 
> >    I've seen the HD light blink when used when it had no reason to go
> > to HD.  From what you said it must have been a log file updating?
> > unless the kernel is using it to swap between daimeons???
> 
>         The logs are written unbuffered, so logs and delayed cache writes of
> various sorts will all cause occasional disk activity, yes.
> 
> --
> Devin  \ aqua(at)nblug.org, finger for PGP;  http://www.devin.com
> Carraway \ IRC: Requiem  GCS/CC/L s-:--- !a !tv C++++$ ULB+++$ O+@ P L+++



More information about the talk mailing list