Slashdot Mirror
Other Uses For The Linux RAM Disk?
Dante_J asks: "Recently I discovered an old Amiga DOS 1.3 Manual I had lying around. While thumbing through it I remembered all the joyful days of good fun hacking. One thing I particularly remembered was how anyone with 3Mb of ram was considered especially blessed with resources because they could copy all their system files into the ram disk and have a 'trans-warp' fast machine on their hands. In this age of more Ram than sense why are Ram Disks only used for Linux installation floppies? Sure buffers are great, but why not mount /tmp to a Ram Disk, and the cache directory for Web browsers too?
Does Linux support dynamically reseizing Ram Disks? Surely they would be vital in remote booting, diskless thin clients."
The problem with allocating that much ram to just hold cache for a web browser or similar program is that they're designed to expect that disk cache to be very VERY slow.
So you'd be better off just using that memory to allow the OS to buffer disk accesses and your programs to do their own in-memory caching than to have it act as a ramdisk.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
I never tried it on my linux box, but I know it always sped things up on a Mac.
If I have ram it's going to make more executables fit in memory at one time. Persoanlly why don't you just get a faster drive?
Respond to s
The 2.4 kernel does support dynamic ramdisks.
People have been putting their NS cache into ram disks on Macs for a long time now, it speeds things up considerably.
Isn't that basically putting what's most important process into the ram disk to make it run extremely fast?
I'd rather have someone respond than be modded up.
Maybe I'll try this at work, I've got over 300 megs there.
Too bad RAM prices aren't dropping like disk storage prices...
That being said, in some respects, its a denial of service attack waiting to happen, though probably no more than a malloc() loop...
Instead of using eterm, use something smaller, like rxvt.
--
Peter
"Sure buffers are great, but why not mount /tmp to a Ram Disk, and the cache directory for Web browsers too?"
Or, you could simply increase the size of the Memory Cache in Netscape. Edit...Preferences, Advanced, Cache, Memory Cache Size.
I'm not enough of an expert on Linux's tmpspace to comment on that part of the proposal... but IMO, it seems like a really bad idea.
--I hate people when they're not polite -"Psycho Killer", Talking Heads
Using a ram-disk to cache web-content seems a bit strange.. Most browsers I have seen already have options for setting how much ram you want to use for cache, and all you would have to do is increase it. When it comes to /tmp, if you have enough ram, Linux will just write-behind cache the file until its use is over.
Speaking as a person who does program the kernel looks like ancient Greek written by a dieing man. Also isn't creating more and more programs in dedicated kernel mode a really, really bad idea? Isn't this what causes NT to die hideously because of it's integrated kernel graphics mechanism?
Respond to s
I was under the impression that disk caching renders ram disks obsolete except for the cases where you want to be absolutely certain that the data stays in memory (such as when your files are on removable media).
- files disappearing from
/tmp on reboot which users didn't expect
- large files eating up swap space
Personally, I find it a great idea; just some admins don't like it as much.--
I haven't looked into this at all, so I could be totally off in left field, but wouldn't it be possible to run a chroot jail's storage on a ramdisk? If the content of whatever is in the jail doesn't really change then I don't see how it would matter if the jail were lost, and I would assume that it would be easier to remove a potentially hacked jail by removing the ramdisk or restarting the computer (not that I am in favor of restarting, I don't think that it should ever be necessary). It would also be interesting to boot a box from CD, dump the 'live' distro into a very large ramdisk, and run it that way, so if someone rooted the box and installed their rootkit, a simple reboot would remove all their changes...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
Where I work, we use a bunch of Linux boxes to serve our website. Currently, all of our content is located in ramdisk, as well as a data cache used by the web applications that we run. I'm currently on a project to evaluate the merits of using hard disk for this as opposed to the ramdisk that we're currently using.
The results of the performance test that I ran were somewhat surprising - it seems the machine with the hard disk actually performed _better_ than the machine with the ramdisk. I'm not a kernel hacker so I don't know exactly why this is the case, but I know that the buffer caching in the kernel really kicks ass (we're running 2.2.10) and I suspect having a ramdisk hampers the kernel's ability to manage the buffer cache (i.e., it takes up space that could be used for buffer cache). Just my $.02...
-VoR
It's pretty easy to set up a ram disk on a mac. So, in the past, to speed up browsing, I created a ram disk on the mac and moved netscrape's cache folder to this ram disk. This sped up browsing quite a bit since the cache files weren't physically written to disk. IIRC you could even save the contents of your ram disk upon shutdown.
If you have a slower machine, particularly one where the disk is the bottle neck, and also have ram to spare, this can be an effective tecnique.
Of course, disks are pretty cheap now...
No one got beat up more often than the mimes of the old west!
Using an EEPROM would allow you to upgrade/patch the OS as necessary. Also, some clever engineering would make it all but immune to viruses (putting the OS in a true ROM would do wonders for virus protection, but make it difficult to upgrade you system software).
Hell, you could put Linux and X-Windows with the Window manager of your choice all on an EEPROM and have a superfast, instant booting machine.
I'm sure this is being done somewhere. Any ideas or links anyone cares to share?
-----
"You spilled my egg... I needed that egg."
It's better to use ram to do BFS to figure out how to beat your friends when playing connect four or the like:)
There's no reason to put the netscape cache in swap. There's already a setting for memory cache as well as disk cache. Personally, Netscape takes up enough memory already. Besides, do you really want 20-30M of RAM wasted when Netscape isn't even running?
That's why people always use it. Supposedly you can use it to make the window transparent. I wish the tend would go away from massive programs that are memory hogs into creating smaller programs that have optional smaller components that can be tacked on at will.
Respond to s
Seeing as RAM these days is getting, like, 2Gb throughput (in my benchmark program anyway), that's 100x faster than a really speedy hard drive...
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
a friend of mine tried it out, and it worked, but do you really gain anything from things like this?
It gets mounted on
Both ShareTheNet and Linux Router Project load the OS into a RAM disk. They do this for the sake of security (just reboot, and voila: new OS installation) and speed. I use a ShareTheNet router on a 386/33 and I regularly see D/L speeds in excess of 100KB/second.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
You might have an otherwise busy computer
/tmp on solaris
that is serving thousands of httpd requests
from harddisk and your filesystem cache is
flushing itself over and over again, and you
still want netscapes cachefiles to be in a
speedy environment?
Of course, having more RAM than disk is a fine
solution when the OS buffers with your free mem,
but obviously everyone can't have that.
Having a dynamic ramdisk (like
and the aforementioned amiga-ramdisks) is quite
a big win speedwise for many kinds of situations.
As long as you have free mem, tempfilecreation
will go nearly as fast as ram allows, and whenever
it gets full, you get swapspeed, which is more or
less what you would have gotten in the first place
with the cache on local disk anyhow.
-- I'm as unique as everyone else.
Better yet, would it be possible to load a 200-400 meg vmware disk image onto a ramdisk and then fire it up? I wouldn't expect any major problems, 'cept having 200mb of free ram to load a Win95 image to. soc
- - - - - - - -
"Never apply a Star Trek solution to a Babylon 5 problem."
"It is a greater offense to steal men's labor, than their clothes"
...I am just waiting for the inevitable suggestion that the ramdisk be used for "swap" :)
I think most distributions do make use of ramdisks during install. In particular, it is called 'initrd' or initial rootdisk, to hold all the kernel modules until it can determine which ones are needed.
Just because it's in Ram doesn't mean it's faster. You're still putting a filesystem on it and you have the overhead of the filesystem, it still uses flock(), and if your box dies you lose your data on it.
I looked into this awhile back. Go ahead and make a 200MB ramdisk on a machine with lots of ram. Make an ext2 fs on it and run some benchmarks on it. Then run the benchmarks on your disk. In most tests, my crappy IDE disk outperformed the ramdisk (1GB of mem in the box, so I wasn't swapping). CPU was much higher when testing the ramdisk, at 100%. I think it's because there was no DMA controller being used when using the ramdisk.
Need Free Juniper/NetScreen Support? JuniperForum
I an effort to speed up some calculations I was doing I directed the I/O to/from a ramdisk, rather than the usual HDD. I figured, RAM is much faster than HDD, so I will remove any I/O blocking time. (This particular application was very I/O intensive. Basically, two programs communicating via files. I.e., program A runs a calculation, program B reads the output, generates new input for A, and so on. Very messy...)
Anyway... I found that there was NO speed up. None. My conclusion, the Linux file system caching whatever (I am a chemist, not a kernel hacker), was extremely good. I imagine that these smallish files were rarely ever actually written and/or read to disk. They were just stored in some cache. Essentially the normal use case and the ramdisk case were basically identical in that all of the I/O was in RAM anyway.
Now, these files were small, and updated frequently, and I have tonnes of RAM (0.5 GB), and what not (2xPIII450, SCSI disk,...) so YMMV... just my experience with ramdisks, for what it is worth.
linux 2.4's ramfs dynamically resizes. The traditional method of creating an ext2fs on a ramdisk does not.
__
I've used 5 megs of RAM as a RAM disk for Netscape's cache for a long long time. Since MacOS 8 first came out, IIRC. I also turn off Virtual Memory and turn the disk cache down. Netscape is very fast loading pages from the RAM disk... I recommend it to everyone. Although for some reason, no matter what I set the actual cache size to, Netscape refuses to fill the RAM disk. That's nice, but that means that I have 2 megs or so sitting there empty. Go figure.
The only reason I bring this up is that, if nothing else, the Amiga is a great source of inside jokes, like "Guru Meditation Errors" and "volatile memory"...
I have a "Zero Policy" tolerance.
I have a "Zero Policy" tolerance.
*/
The file system takes care of caching disk access in ram, so if you write to a tmp file, the file system will write to memory (ram), and eventualy write it to disk when it get around to it, or if you do a "sync" at the prompt. If the tmp file is read soon after it was written, then deleted, it will never even get written to disk.
There's no real need for a desktop RAM disk because the Linux kernel is very good about caching pages from filesystems in memory, and adjusting between processes and disk cache. As long as you don't go overboard on processes, your most-commonly-accessed files will remain in memory anyway.
/var and /tmp) everything is read-only, so that you don't need a hard disk, just a floppy or boot ROM.
I could see doing this on an embedded application where all you want is the critical files and (with the exception of
I'm not sure if Linux is smart enough to NOT cache pages from a read-only RAMdisk, because that would be silly... the same data could end up stored identically in memory twice! But that's for kernel-hacking types to deal with.
Pre-note: I hate Windows.
A teacher I had in college did something pretty wacked. He had 16MB RAM on his Windows 3.1 box. He made a 8MB RamDisk, ran Stacker on it to increase it's size to about 16MB, and put the swap file on it.
The speed increase was huge since Stacker is faster than a hard drive. I'm not sure if this is possible or useful in Linux however. It was more important in those days because MS-DOS could only use a total of 16 MB.
Ozwald
In terms of more practical benefits of this practice, it can be useful for preventing the size of your disk cache from getting too large and taking up space that you *really need* for those N. Portman .jpg's and Metallica MP3s and can help to reduce file system fragmentation.
________________
They're - They are
Their - Belonging to them
I don't want free as in beer. I just want free beer.
In all honesty, the kernel knows much better than you do which files it's always accessing, so it can optimize itself better than you.
Type in "free" and you'll see that almost all your RAM is in use -- that's because it's got a RAM buffer of most recently accessed files so they can be accessed again faster. In fact, if you create a temporary file and then delete it, often that file will never touch the disk.
This, of course, is why you have to unmount disks - the unmounting writes the buffers to the disk so that the changes won't be lost.
So, it's already done for you, assuming you want a RAMdisk of your most frequently accessed files.
Sometimes, people want a rarely used file to be easily accessed to reduce load times, which is something that buffering won't help with. So, you just flip the sticky bit on the file, and it's done for you.
By making a RAMdisk, you're taking away from the available RAM that the kernel could be using for intelligent buffering, and actually slowing down the machine.
What was even more impressive about the Amiga RAM Disk, was the variation 'Recovable' RAM Disk ( RAD: ). :-)
(Also know as 'RAM_B0' on OS1.3 and below)
This kind of RAM disk did not dynamically re-size like a normal RAM disk, but did survive a re-boot.
Therefore, when your machine crashed, it would boot off the RAD disk in no more than a few seconds. Very useful when developing.
I suspect that that kind of thing wouldn't be possible on 'standard' PC hardware. Does anybody know of anything like that for the PC?
--- I'm sure using a computer was fun back in the 80's. *sigh*
when you're working in a company taking a close look at security issues it comes to mind that one could encrypt the binaries and sources and start s program that needs to run in ramdisk. Thus it will be destroyed whenever someone tries to lay hand on the computer...
-- a blessed +42 regexp of confusion (weapon in hand) You hit. The format string crumbles and turns to dust
The uses of RAM disks abound!
For instance, I've just finished a multi thread system where I used a ramdisk to do message communications. It was very simple to program and wasn't as demanding on the kernel for interprocess/thread communications. The ramdisk is also a great way for a program to store data in case of a crash. Since there's very little overhead for transferring data into and out of the RAM disk it was a wonderful solution for this.
I hope to write more software utilizing the ram disk in the future because it was so easy to achieve advanced communications between processes. I wasn't confined to signals or using someone's clunky library. (I write high performance programs so anything out of the libc I typically try to avoid because I can make a library tailored to my needs that is much faster than the general case libraries are, but I digress)
As for the scailability of the things, yes RAM disks can scale as long as you have the RAM for it. That is, in kernels 2.2 and up I believe. Anyways you have to use a scailable filesystem like riser to make it go.
I am the penguin that codes in the night.
With KDE eating as much as 190 MB on my machine (including cache files for normal system processes), there's no room left for a sizable RAM disk. And I feel blessed that I have 256 MB at my disposal.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
It's a fairly simple and straightforward sysadmin exercise to make a script (well, one line, really) to delete all files in /tmp that haven't been accessed in say 3 days or so. (It involves reading the manpage on 'find'.)
/tmp at one point, just to ensure that students wouldn't fill up /tmp and bring down the machine.
Heck, at cc.purdue.edu they put quotas on
---
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
Everything that you could speed up with this sort of a contraption you can do with the linux buffers, only the linux buffers are better because they're implicit. QED.
(apologies for the lack of verbosity, but I'm not in the mood to go a'whoring after karma today.)
The problem with using an expanding ram disk is the amounts of money you are going to sink into it for more ram to make this useful. You could spend your money on things that will improve system performance better then this. Like an ultra 66/100 drives and controller Scsi drives or Raid controllers with built on cache. You could also spend you money on a faster CPU. A ram disk in the amiga era worked great for a OS that was under 880K but a full blown Linux OS would cost to much and have very little to gain. Also what happens when a log files balloons up and uses your entire ram disk?
Sounds like a plausible idea, i'm sure that someone will probably come up with some idea that will make it seem entierly unplausible though.
In a modern virtual memory operating system, like Linux, the difference between memory and RAM is very subtle. Disk files are kept in RAM as memory allows, and traded with memory pages from swap on something approximating a "most recently used" algorithm.
If you go and start putting your temp files on a ramdisk, you're subverting this efficient process. Should there be a RAM crunch, the OS will be prohibited from swapping out your temp file, even if there is a much more frequently referenced page of RAM in use.
So don't do it. The kernel is already looking out for you, and it's already taking care of this. A demand paging VM OS is not like AmigaOS, or DOS for that matter.
Maybe someone should do a dist that's optimized to use a 100 megabyte (or so) RAMdisk to speed up the loading of the most used and slowest loading apps. Netscape would probably qualify. All the gnome stuff... star office... The field's wide open.
Of course, that space might be better used as disk buffers...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Thankfully caching is an integral part of most operating systems these days, so RAM disks are pretty much useless as "accelerators". At least in the case of Linux, multiple instances of the same memory or executable all point to the same physical memory, with some nifty copy-on-write (COW) tricks. This actually works faster than traditional caching in some (most) cases.
/tmp in RAM is a nice idea but it's questionable what the advantage is, seeing as it can get swapped to disk.
All a RAM disk does these days is deny any unused RAM disk space for usage by the system. The only possible reasons anyone would possibly want a RAM disk these days are:
- When your backing medium is removable/doesn't exist (e.g floppy root disks or diskless machines).
- When you absolutely must have a file's contents in memory for latency reasons, but there are others ways to guarentee this (use mlock() for instance).
In the example case of the 'trans-warp' Amiga, if the OS performed page caching and had enough RAM, it would never touch the hard drive after all pages were touched. The fact is the traditional use of RAM disks for acceleration is obsolete - page caching in the OS has replaced that.
The Solaris
Yes, but the question is, WHY are we talking about Linux here. Another problem where FreeBSD has already solved the problem, but now that the Linux community has discovered the problem, they'll throw in a hack job and say it's better than the BSD implementation as usual.
For remote-booting thin clients I would recommend the network block device. It allows you to mount any filesystem on a TCP connection, although you can't use it for swap space (at least not in 2.2-series kernels).
I've been working on a Linux install on a dedicated RAM drive for awhile...
I have a prototype Platypus Qikdrive8 that has 2GB of RAM, and is addressed as a mass storage controller. Installing on the device is a little tricky, but wow. Fast, mang. Bummer if you lose power, but there are ways around that. (Check the URL). It's cool for non-production use, but if you have the entire system running in RAM, well, it doesn't give me a warm fuzzy. Platypus for one is coming out with a HD-based backup system (data dump from the device to the battery-powered HD if power is lost) for their large RAM drives. That could be the answer. -JPJ
Feh.
I remember when I used to have an Atari ST, and everything was loaded off floppies (sloooooow!).
I used to regularly put multi-file games (one file per level/map, etc.) into a single executable file that loaded them into a ram disk upon running (and packed (compressed) the executable) - I prefered the slightly longer wait to initially load the game, rather than having to wait between levels whilst files were read off the floppy.
Disk caching only keeps files in memory that have been accessed previously - the above technique acts as a pre-load for files that will be needed later.
[Happosai]
Unix/Linux does this for you automatically. The disk caching functionality will keep the disk blocks belonging to recently used programs in memory -- so if you have a lot of memory, you'll simply find that once you've typed a few commands, the machine doesn't have to go to disk to fetch them on subsequent runs.
This actually reflects the perfect way of doing this: add optimization, but don't bug the users about it -- it's not their problem.
--
Tired of FB/Google censorship? Visit UNCENSORED!
Ramdisks are ideal for laptops, where accessing data in memory doesn't eat battery life as fast as moving around all those mechanical parts in order to do a disk seek. At least in the old days, when you copied all your system software + a couple important applications to a ramdisk, it'd boost battery life considerably.
I'm not sure what SMP capability has to do with portability or RAM disks, but I'd have to agree. Linux machines seem to be built to work with tools like the GNU tools; FreeBSD is BSD (as close as a *BSD can come to being exactly like another) and therefore works with FreeBSD and...well...FreeBSD.
:^)
Try to compile FreeBSD's "chmod" on a Linux box sometime. Ugh. (Yeah, I know; that's irrelevant too.
Stating on Slashdot that I like cheese since 1997.
>Yes, but the question is, WHY are we talking
>about Linux here.
The answer, from the original post.
>Does Linux support dynamically reseizing Ram
>Disks? Surely they would be vital in remote >booting, diskless thin clients."
If you think that it's a viable option, why not help draw up some sort of plan for porting the solution? Or did you *really* think that you could persuade someone to use FreeBSD? If your plan was the latter, you're just another troll.
Stating on Slashdot that I like cheese since 1997.
Where can I find it? And how fast is it compared to a plain xterm? One of the reasons I hate ETerm is that screen refreshes are SO FLICKERY SLOW, even if I shut off the background pixmap. xterms are pretty snappy by comparison.
--Joe--
Program Intellivision!
When the third drive died on my powerbook 180, I created a seven floppy boot-set. I had the thing maxed out at 14mb, so I could install system 7.1, word 4 (I'd been using 5, but backtracked), and excel 3, along with my usual utilities, and still have enough room left to work . . .
Of course, given that batteries were only good for 1:40, and that some genious diddn't include a capacitor to back up ram while changing . . .
hawk, who still has the pieces of that machine
The same is probably true, today. Simply because few people will be able to test and refine the code on extreme memory machines, RAM Disks will probably still be the way to go.
There is -one- other case for RAM Disks that I can think of. =VERY= Extreme RAM cases. Where the size of RAM is comparable to, or exceeds, the size of the HD(s), it is not efficient to keep swapping to and from drives. They're slow. It's much faster to simply dump the drive(s) to RAM and write-through to disk a you go. All actual read operations, after boot, would be to RAM.
Beyond that, fast IDE's or SCSI's, with decent on-board cache, are all-round a better idea than RAM disks.
Going back to the extreme memory case for a moment, this would be ideal for a laptop. Non-volatile RAM is going to eat batteries far less than a mechanical drive. (Especially on power-up, or where there is extensive disk activity.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Oh boy! Virtual Memory! I'm going to make a HUGE ramdisk!
--
My word processor was written by Stanford Professor Donald Knuth. Who wrote yours?
A machine with 512k that is a personal work station coul dhave 256k for memory, 128 for /tmp and 128 for swap. This could add in that necessary performance increas I need for video.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
I been using the BSD equivalent, mfs, for my /tmp directory for a few days and have noticed a suddle improvement in X performance. All the documentation i've read about mfs has given increasing performance of /tmp as an example. I believe mfs is also resizable. I'm not sure but it would be logical if mfs didn't use file system caching. If this is true then mfs is a way to give one application which uses a directory priority for having it's files stored in RAM to boost it's performance above others.
As far as increasing web caching performance, a better approach is to use squid, which has the option of storing things in RAM without the need for creating a file system. Also having a huge disk cache speeds things up since disk speed is faster then network speed.
Create a ram disk on a win32 machine and install quake to it - the dir only has to be like 70Mb so something - so if your running round with like 256 its no problem, then play quake.
It flies :)
Aminal - DRUMMS!!
Many many motherboards allow you to install more RAM than their L2 cache can handle. My Asus P5A can only handle 128MB, for example. Add more RAM and it's acessible, but not cached. So things get dramatically slower.
The slow ram can, however, be used as swap. Much faster than a swap partition on a hard disk, though obviously not as good as real cached RAM.
I've got an old VLB 486 motherboard. And I've got a cacheing VLB IDE controller which takes 30-pin SIMMS. I figure I'll keep the OS on a SCSI drive, and put in an old 40MB IDE disk with a 16MB swap partition and 16MB of cache RAM. Should be a pretty fast swap disk. I just need to find the time to set it up. :-)
PHEM - party like it's 1997-2003!
I think you just earned the "top suggestion of the quarter" award.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
The only real place I can imagine where this might help is one where there is a lot of disk writing going on on a particular filesystem, and the system is so busy it never has a chance to flush it's cache without causing incoming requests to wait, such as a way overloaded mail server (I've seen this). Of course, the problem there is that it's not a night and day performance difference anyway when you're talking about modern disks with built in caches and OS's with decent lazy write techniques. And of course the little tiny issue that you're completely compromising your data integrity since if the system dies, everything in that file system goes with it. A far better solution, if you feel you must second guess the OS's caching/paging/vm system, is a controller card with on board cache and a battery backup. This maintains your data integrity, and will give you a little performance boost for busy disks with lots of writing. Of course, you'd still probably see just as much performance improvement by adding memory...
For a web server, I thought it would be interesting if the OS were run on a ram disk. chroot to the ram and if a cracker got it and modified files, it wouldn't be difficult at all to fix.
Could even have lids just reboot the box on signs of trouble
Dyslexics Untie!
Using this with the Livid project. Surely a RAM-based FIFO would be quicker than a disk-based one?
Valid point, even though you only have the 0. This may explain, also, why RAM disks aren't really any faster on a Linux box than just reading from disk.
Stating on Slashdot that I like cheese since 1997.
Sorry, no. You'll have to run Windows 98SE for that pleasure. Linux is unnecessarily stable for such a task.
Mr. Ska
All of the data stored on your disk is already proactively cached, most recently used is much more likely to be in cache longer.
Full blown RAM disks have limited applications, especially when the buffer cache can almost always do a better job. If you have gobs of RAM you're not using, increase the size!
That's exactly what I used to do with my Apple IIgs with a utility called FlashBoot. I could create a disk image with the software I needed (the OS and AppleWorksGS) and load it into a RAM disk. I think the RAM disk took up about 3M of my total 5M (which cost me about $300 by the way!). As long as the computer stayed on, things ran pretty fast! (at least for a 4MHz processor)
hope no-one minds a swift summary of the responses to the question: why not use ramdisk more?
Case FOR the motion:
Case AGAINST the motion:
My conclusions? Ramdisks are mainly an anachronism from an earlier time before better solutions to the problems became available, and are better left alone. Performance and/or resource utilisation efficiency is better served by more specialist tools such as caching, sensible application design, network block devices etc etc.
--
I'd rather have a bottle in front of me than a frontal lobotomy
What about hardware RAM disks?
I've seen some (don't remember where) that were designed to be used like a normal disk but on the insides they were a bunch of battery-backed RAM. I believe the high-end models even had the ability to automagically sync to a physical disk in the enclosure on power loss/off/shutdown and restore to RAM.
I think the advantage of these solutions over a conventional host-based RAM disk was that by treating the RAM disk as a SCSI device you could make it much faster than conventional host RAM (special controllers, interleaving, etc).
I don't remember the name of the company that was selling this and they don't appear to be around anymore. Maybe the cost of RAM relative to the sizes people needed just made it commercially impractical.
Linux installation from floppy uses the RAMdisk to store the installation filesystem. This is not only quicker than running from a floppy, but allows the RAMdisk image to be compressed. Debian and Slackware do this, and I presume other do as well.
When I've used RAMdisks in the past on other systens, it has always been when other media was slow. A common one was under DOS on a floppy only 8086, copying COMMAND.COM and to a small (30K) RAM disk (stored in spare RAM on the non-standard video adaptor IIRC), and setting COMSPEC accordingly. Saved me having to swapp floppies just to load COMMAND.COM on program exit.
The only advantage I can see on a non-embedded Linux is if you have a some data or executable that you need to guarantee is in cache, and pre-load this into RAM disk before-hand. Faking benchmarks springs to mind here.
If anyone wants to argue that /. is going downhill, this is prrof enough. Just because one person doesn't know that ramdisks are very often used, is it really worthy of posting? Last time I checked this wasn't a technical support forum!
Do you think my question would be posted if I asked what license Linux is released under? No? Than why this, asking what uses ramdisks are.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It seems that a lot of people here don't really understand how the bowels of a modern OS work. Now, I'm not claiming that I'm an expert at this. But I have read some OS books, and they do point out why it's no use.
Basically, your memory is divided in pages, which are kept all on disk. The pages that are needed are brought into physical memory, the other ones stay on disk. Very finely tuned algorithms make sure that what's in memory really needs to be there, to optimize efficiency.
Now, if you force an entire file, or even partition, into ram, you're inevitably putting a lot of data in your memory that doesn't get accessed. If you put your NS cache in there for example, then you have extra space for growth that's being wasted, plus all the space taken by cached pages you're not revisiting, and are thus wasted.
So, basically, your app may go faster, but your system will go slower, because it has less physical ram to hand out to everything, so it can keep less in physical memory. So, the best choice still remains to let the OS decide what belongs in physical ram, because it knows best what should be there.
So. Why did it work years ago on the old systems? Because they had no harddrive. Paging to disk was too slow due to the extreme slowness of floppy drives. As soon as harddrives became a commodity however, paging to disk became so fast that it ruled out ramdisk as a speed option.
The reason the install floppies use a ramdisk is because they have so little to load during the entire install that it can all be held in ram, so they run out of ram because it's faster (and they can't page to disk anyway, since you need to be able to wipe that clean during the install).
And then finally we come to the point mentioned that the swap should be in memory. Think people! The swap is the spillover for everything that doesn't fit in memory. If you put it in memory you'll be able to fit just as much (or most likely even less) stuff in memory, leaving you in a situation where you're not going to be able to load as much apps. In regular (light load) use the swap isn't even used all that much. Only stuff that's just hanging around doing nothing (like that sshd you rarely use to log in with) will get swapped out (negating the point of not running a rarely used daemon because it "takes up memory", which it doesn't).
Solaris uses RAM plus disk for /tmp. It'll put everything in RAM till the ramdisk is full then start using the allocated disk space. It works very nicely, too.
---
--
If I actually could spell I'd have spelled it right in the first place.
My parents have a Performa 6116; it has a PPC 601 @66 mhz and a 33 Mhz bus. Running Netscape 3 is quite a task for the poor machine (Netscape 4 is right out :).
It was even more of a task before I did just what you described and made a RAM Disk and told Netscape to use it. Sped it up by about 3 times.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Yup. I did that too. A500, Workbench 2.1, 20 meg SCSI hard disk.
Even though the 880k of RAM could have been better used for program space, I found that the performance penalty of having the system files on a slow band-stepper hard drive was such that the memory hit was less obtrusive.
And, I had a later-revision A500, into which I'd plopped a Fat Agnes chip. With a little hacking, of course, it was possible to set up the memory expansion on the bottom of the A500 to become an extra 512k of Chip RAM; the 2 megs in my hard disk controller setup was the Fast RAM.
The only reason I bring this up is that, if nothing else, the Amiga is a great source of inside jokes, like "Guru Meditation Errors" and "volatile memory"...Or, if you've been downloading too much off the local high-speed (2400 baud!) Warez BBS, "Your Amiga is alive..."
Ya know, a Mac says, "Sorry, a System Error has occurred"; Windows tells you that "This program has performed an illegal operation" or any number of other nasty things.
But, besides Eudora 3.x ("Eudora is tired of waiting for the system to respond."), can anyone else think of any really nasty or sarcastic error messages like the Guru Meditation Error?
Fire and Meat. Yummy.
While testing the databases for SourceForge we found that by mounting /tmp as a ram disk we saw about a 10-20% performace boost.. works great.
- U
what i love of this idea is the fact that a true hardware system can react a hundred times faster than a hard-/software system as used today for pcs. think of a linux reacting within nano-seconds to input -> kewl thingie. if you'd program the linux kernel in vhdl (this is a c++-like hardware programming language used to create chips), you could get great performance out of it! so, lotta work for the electronic experts - like me :))
mephinet
Use the source, Luke!
I was thinking to convert my /usr (which I mount read-only) to iso9660. Would that reduce fragmentation?
/usr into another partition, install/upgrade there and then mkisofs it back it can be done.
/usr in memory: it's already there, execute it from there. The same with shared libraries.
I am looking for a _simple_ filesystem to store a bunch of read-only files. There is no need for all the metadata overhead and I guess iso9660 will do it.
Of course it will make upggrades harder, but with some script to copy all the
Different subtopic:
I am not interested in a dumb ramdisk: it is stupid to load programs from ramdisk into kernel caches/buffers and then to main core.
Optimize the kernel so it does not need to "load" a program from
THAT would be a FAST system.
In Linux, all unused memory is used for filesystem caching. In general, linux does this caching mcuh better than you could by mounting specific disks and files in a RAMDISK. Linux chooses things which are accessed frequently, or very recently, among other things, into this FS chache.
By creating a RAM disk to do this, you would force a much smaller subset into memory, which would be great for what you are using there, but would hinder performance on other things which linux does not have the room to cache now.
So, unless there is something very specific that needs to be cached, there is no rationale for this, and the chances are that linux will cache it for you anyway if its that much of a performance hit.
Last but not least, the biggest reason RAM disks are slightly faster than average (when linux does cache) is because they never have to synch to a physical medium. If you dont care that all the data you have written there is gone *poof* once a crash occurs, or if the system is shutdown, then thats ok. If you have a file there, and 'oops' forgot to write it to disk, its gone.
Posted by polar_bear:
You know, I have nothing against any of the *BSDs, but some of you BSD-bigots really get annoying. A guy posted a question about doing something with Linux, he didn't ask if other OSes could do "x" he asked how to do "x" under a particular OS. Leave it alone. It's all free UNIX, it's all good, get over it.
Sure, FreeBSD does some things better than Linux - so use FreeBSD and let those of us who prefer Linux use Linux. I personally think Linux does nearly everything better than Windows or the MacOS, but I don't feel the need to insult and annoy Windows or Mac users with "why try to do it on those OSes - use Linux instead!" (Of course, if a Windows or Mac user asks about Linux I'm more than happy to share what I know...)
There are quire a few gnu tools being used by FreeBSD. Grep and tar come immediately to mind. And FreeBSD does have SMP, now it's not the best but it works acceptably (I've used it). That should change soon when 5.0 comes out though.
Linux talking about portability is rather amusing. How many linux developers right truly portable apps? The number of times I've had to fix a linux app so i could run on Solaris or BSD is very high. One shouldn't pretend portability where none really exists.
this space for rent
Just wondered if mixing this with the software layer in Crusoe would help patch future releases of the os (with a software layer upgrade for the chip) Dont know if its possible - but i want it :)
Even though the lack of a swap file capability for the Amiga meant you sometimes you didn't have enough memory to do some things it did give you a certain philosophy that worked well.
If you can run it, it will run well. If an app _has_ to use lots of memory because of it's fundimental nature (such as image processing) it will intelegently do the swapping itself.
Because memory was not considered vitually unlimited people developed with an eye towards keeping memory requirements down.
The requirements of programs for OS's with swap files have rocketed over the last few years.
It's sad to see the Amiga style of operation disappear without any debate as to the merits of it. People made swap files because they could, not because they were essential.
Bill Gates reputedly once said '640k should be enough for anybody'. In my own mind I think that 64 meg should be enough for most people, yet I routinely do tasks on 64meg machines that are swapping merrily away. It's not because I'm not considering the possibilities of things that could be done (Like Bill did) but rather that I feel that those things could be done in 64Meg. I fell like my memory is going to waste.
I have ICQ running at te moment. It's using 6 meg, I haven't a clue what it actually puts in that 6 meg. If memory were not considered unlimited how much would it be using?
-- That which does not kill us has made its last mistake.
Firstly, ramdisks steal memory away from running programs and they completely defeat the purpose of disk buffering. Another thing is that a ramdisk could potentially run out of space and most os'es (including Linux) don't like it when they run out of space on a "storage device." Many times, the memory that is occupied by the ramdisk would be better off used by running programs. Also, think about the case where you run out of ramdisk space and your ramdisk is using swap space instead...then what happens??? Your OS will wind up calling something from your ramdisk which is then redirected to your swap space when it could have just as easily read it from your HDD in the first place. Another scenario: your computer runs out of available RAM and your OS is forced to operate some of the running programs out of your swap space...again, you have negated any performance gains. In short, I would suggest that you would be better off allowing your operating system to manage its own memory and disk space.
# They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. --Fran
Windows 95 etc. does use a write-behind cache for hard drives by default. You can turn it off in Settings, Control Panel, System, Performance, File System, Troubleshooting (that's a lot of clicking...).
I wonder if anyone cares about my useful tip for making Windows more crash-tolerant... (my sense of humor is horrible today, really) *grin*
You have to admit that if I somehow got an "Ask Slashdot" posted where I asked the question: "How do I get my Windows 98 box to recognize 4 ethernet cards without crashing?", I'd get the following five answers:
1. Works fine for me - under Linux.
2. Why are you using Windows?
3. Linux supports theoretically infinite ethernet devices.
4. Natalie Portman!
5. FUCK YOU AND YOUR WINDOWS BOX, YOU WHORE
"Beware he who would deny you access to information, for in his heart he deems himself your master."
I keep perl, python, Eterm, and zsh on a ram disk.
Those are programs which are often spawned, but unlikely to be cached.
My xterms open noticeably quicker since zsh and Eterm don't need to be loaded from disk each time. Perl and Python scripts are executed much quicker as well since I don't have to wait as long for the interpreters to be loaded.
A friend of mine uses a RAM disk for his Netscape cache. It saves him the trouble of having to clear the cache out manually on every boot. (He is on a Mac.) I have been considering doing something similar on my Linux box, but too many things are already needing to be done.
"Trademarks are the heraldry of the new feudalism."
The reason ramdisks were so useful on your old Amiga was the absence of a good disk caching program. Linux has excellent dynamic disk caching, you're better off letting the kernel have that memory to play with instead of locking it into a ramdisk.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
if you had an install where a very select amount of info was reused a great deal. Say a web server that serves only a few very small pages but takes a huge number of hits or a database that is VERY small.
There are instances where it could be a usefull tool. Not very many that I can see though. As far as a home system goes, you generaly wouldn't have the resources to spare. Maybe if you have say 1GB of ram. In that case you could probably spare some and not notice the differance elsewhere. but at that point you most likely have a system so fast anyway that you couldnt realy tell the differance in speed.
Well, Macs have had the ability to make RAM disks since back before anyone had enough RAM to make them useful as well, so maybe some of my experience with them will apply here. Web caching is not really a good use for a RAM disk. Since most of the files in a browser's cache are pretty small, if you have anything better than a modem connection, you may even be better off turning off disk caching altogether. Large files, such as .mp3's, may benefit more from running off a RAM disk. This is basically like buffering the whole file into RAM before playing.
The largest benefit of RAM disks seems to come to applications on the disk. Since the executable is already loaded into RAM, it should start much faster. This may not apply to Linux, but some older Mac code was 'segmented' so that only parts of the executable were loaded into RAM at once. Having the application already entirely in RAM also speeded this up.
Personally, I've tried using a RAM disk as a browser cache, a boot volume and a temporary place for power-hungry games. I noticed marked performance increases on both booting from the RAM disk and running applications from it, but no appreciable difference for using it as document storage.
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
Back in the late 80's we did this with an Amiga 2000. We bought a multi-eprom board and mounted it in the A2000. We burned the whole amiga OS into EPROMM. The machine booted the OS Instantly!. There were 8 EPROM slots in the board so we had the Whole OS and some small, heavily used programs burned into the EPROMMS. It was awsome!
Of course the Amiga was a hardware hackers dream machine. It was nice having multi-rom boards so you could boot up with Amiga OS 1.1,1.2,1.3,2.0,2.1 at any time. A TRUE multi-boot machine.
I don't see why you couldn't do this same type of thing with Linux. There are a few different "Embedded Linux" distros out there. Just burn them to EPROMM and "Hack" the hardware! Boot from an EPROMM board vs. hard drive. And have the EPROMMed OS mount your hard drive(s) to the OS. Easy? maybe not for the faint of heart. But a truely driven individual could do it.
If someone gets it to work let us all now. Share the wealth per say.
The Truth is a Virus!!!
The Amiga system was a shared memory ram based os. When you loaded a program into ram it was never paged out because there was no vm support. Also because it was shared memory you could make pointers to programs in memory and run many copies of the same code without using much memory for each extra copy. The Linux ram disk is slow because it is trying to emulate a file system. Look at the work that sgi is doing with apache and loading htmml pages in memory. Memory is much faster then hard drives but we have to create a completely different core to take advantage. You can have fast and unsafe (shared memory) or slower and safe (vm).
As I recall, my Tandy 1000SL (this was back in 1987 or so) had MS-DOS 3.33 (and Cassette BASIC!) in ROM. The DeskMate environment was there as well, but you still needed to load the DeskMate modules from disc. IMHO, it was an -excellent- idea, on the 1000. The 1000 was a low-end machine that rarely had a hard drive (I got one of the first that had the 3.5" floppy available). The machine booted up in seconds, and brought you a DOS prompt without requiring any magnetic medium. Compare this to waiting nearly a minute for DOS to load from a floppy. The difference becomes even more marked when you realize that you could actually load the DeskMate UI from ROM, as well. You wouldn't have any modules available, but the UI would just blink-up (and this is on an 8088) without having to wait for discs to spin-up. The manuals for the 1000SL made levity of how slowly the 1000SL loaded from disc--I don't think floppy-cache cache wasn't an option, I'm sure it was read straight to RAM, which probably yielded a lot of dry-spins on the disc. That being said, I think we're past the days where we need to worry about such things. Permanent, reliable secondary storage is all but in a glut right now.
Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
I have a fellow sitting beside me at work who has a RAM disk on his Win95 box. I asked him why. His answer: "The icon looks cool in the My Computer folder".
Can you say the same about a Linux Ramdisk? Bet a MAC one looks *really* neat.
Going on means going far
Going on means going far
Going far means returning
Okay, after having read the above discussion, and seen how everyone is in agreement about the following points...
/tmp filesystem on a ramdisk. Make the ramdisk dynamically resizable. If the ramdisk gets too big, then vm will page it out to disk. But wait! There's more. If the vm system is too slow, or runs out of real disk space, then you could make it use a swapfile and put that back on the ramdisk under /tmp.
* Everyone has plenty of ram to spare
* Putting ramdisks into Unix is a great idea, for all the reasons others gave in other threads
* ramdisks have such a large positive effect on performance in the post-floppy disk world
...and in the true spirit of Microsoft innovation, I propose the following:
Put the
The wonderfulness of this concept is that it involves no hacks to the Linux kernel, and so wouldn't give the BSD bigots anything to say. Furthermore, even in Microsoft's view of "innovation", this would be an innovation unmatched by Windows.
Hmmm.
(Reminds me of my idea for a generator on an electric car to keep the batteries fully charged while the car is driven. Oh wait -- I don't have the patent filed for that one yet.)
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
The company I worked at previously had a daemon which was receiving 1500 requests every 30 seconds, each of which resulted in a dbm open/create, update, and close. After 6 months of incessant drive chatter, it killed the disk it was running on. We then threw 1/2GB of RAM at it and tossed the files into /tmp (on Solaris, so it was effectively RAM). System was much quieter, a little faster and we didn't torch anymore drives. RAMdisks come in very handy at cutting back on hardware stresses in cases like this.
Every filesystem type comes with a special set of options you can use when mounting one of those filesystems. For Solaris' tmpfs, you can set the maximum size of the "partition" so that it won't actually use up all of swap.
Most admins bitching about the large files problem aren't aware of this option. (I wasn't for a while.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
We use heavily Linux Ram disk in at least 2 subsidiaries of my company.
...). The data are coming from a NetApp. So a box function is only related to a MAC address.
All the box boot using dhcp, and get an OS ram image dedicated to a job (web server, mail server
When the kind of processing needed or the configuration doesn't imply concurrent write access, the benefit is twofold:
- easy hot swapping of boxes (just boot an another box using the failing one OS config);
- easy and cheap computing power expansion (clone the OS config, add a MAC address, an IP and a DNS entry and you're set.
The boxes of course don't have swap, and the performance is not a problem when you consider the gain in ease of maintenance.
An other usage I plan for it is splitting my home computer in 3 boxes: a super silent stripped down box with just a good sound card next to the hifi; a super silent stripped down box with a good graphic card, keyboard and screen as console; and a fat server with lot of disks and CPUs (at least 2, the 8ways Xeon are a bit expensives) in some place where the noise is not a problem. Now if someone knows about power supplies which are quieter than 34db, that's interesting me!
Nicolas
Of course SCO Unix isn't Linux, but I'm sure that this principle still applies. If you think about it, the buffer cache has more smarts than Ramdisks. It contains which disk blocks really have been most recently been used. Ramdisks, on the other hand, don't maintain any usage information, which means you're using your memory to hold disk blocks that aren't the most frequently used. Files can hog memory in a ramdisk that are never been used, while the buffer cache will eventually flush unused blocks.
Another problem with Ramdisks is sizing it properly. It's got to be big enough to hold everything that goes there with as little extra space as possible so you use as little precious RAM as possible. At the same time you want as much extra space as possible so it doesn't run out of room when Slashdot links to your site. And you can almost ensure it will run out of room anyway, probably in the wee hours of the morning.
Some other posters indicated that Linux will simply start using swap space when the Ramdisk fills. Not quite; Linux will treat the Ramdisk just like any other partition that fills up. This means that applications can't perform add anything to the disk, which in turn usually means your applications crash and burn.
So here's my view on Ramdisks: don't use them. It's better to just crank up the size of the disk buffer cache if you really need the increased performance.
As for why not to use memory filesystems, it's because most implementations have the memory filesystem as a device not unlike a harddrive, and then place a filesystem on top of that. So you've got the overhead of a filesystem on top of the overhead of the memory disk.
As a rule, they aren't worth the hassle. Like most filesystem discussions, there _are_ cases where a technique shows its strengths. Memory filesystems have more weaknesses than strengths.
-bugg
any ram you put into the ram disk takes away from space available to the buffer cache..
:-)
Not only that, but your buffer cache will *still* be buffering your RAM disk, so all of your data will be stored twice in RAM. There may be a way to bypass this, I'm not sure.
It's not surprising that if you took a significant chunk of memory for a RAM disk, you'd get *lower* performance.
There are almost no applications that are *good* for a ramdisk. nvram disk is another story altogether.
One of the Fundamental differences between all Unixes and every other OS ever invented is the use of memory to buffer the filesystem.
Actually, disk caching is NOT a unique idea at all.
Macs have supported a disk cache for performance since at least System 3.0, in 1986. You can see a history of the old Mac OS here. However, I'm not sure if this is a read cache only and what form of cache writing scheme it supports if any nowdays.
While I can't really say about the DOS-based Windows variants, the NT versions of the Win32 API has lots of support for asynchronous file I/O. By default, all normal disk writes are written to a disk cache which is lazily flushed. You can specify certain options when opening a file handle with Cre ateFile() to force it to write straight through to disk rather than lazily cache it. In fact NT gets its asynchronous packet-based I/O subsystem design from VMS. (The designers of the NT kernel were ex-VMS designers.)
Finally, while I can't speak about the Amiga, I can speak about MVS's descendant OS, OS/390, which can handle asynchronous file I/O. I can't find you a good link, but most of the references I could find on this talk about OS/390's UNIX services. Apparently around release 2 of OS/390, they began to comply to the XOpen definition of a UNIX, so I guess that doesn't help that much.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
VD0: was a recoverable ram disk on later versions of the Amiga OS. Very convenient.
/tmp could be a problem in multi-users environments, but it might be a nice option for Linux home users.
I can see where ram as
"I might have made a tactical error in not going to a physician for 20 years." -- Warren Zevon
Now what I'd really like to see in Linux is the Amiga "resident" command. (For non-Amigans, resident was a command that would load executables into resident memory. In Linux, this would take the form of a command to tell the disk cacher to load this file into cache and keep it there.)
--------
"I already have all the latest software."
insmod rd rd_size=128M /dev/ram
/mnt/ram
/dev/ram /mnt/ram
/mnt/ram/swap
/mnt/ram/swap
mkfs -m 0
mkdir
mount
dd if=/dev/zero of=/mnt/ram/swap bs=128M count=1
mkswap
swapon
how useless.
ramdisks are cool to put your netscape cache in though. that way, when the fbi comes knocking, they cannot see what sites you have been, since the cache is in a ramdisk that is deleted when the ram loses power.
Why read the article when I can just make up a snap judgement?
I want my PIII to boot like a C64!!
-- Periodically spray diskettes with insecticide to prevent system bugs from spreading.
Because it was a hack job.
And can you even do that in g77?
Anyway, it wasn't worth it to me to figure it out. Maybe if I was really going to "put my name" on that program/technique i would have done it "slicker."
Why in the world would you set your web browser cache to a RAM drive? Most web browsers already have the ability for you to set up a RAM cache that will be used in its entirety before caching anything to disk.
And besides, if a program would benefit from a faster RAM-first, disk-last style cache, it should be the program designer's job to cache things as memory and let the OS vmm swap memory pages in and out to disk as needed.
- "It's just a matter of opinion!" - PRIMUS
Obviously this will be vulnerable to failure, but for something that collects massive quantities of statistics, such as Ifile, it can be worthwhile.
With Ifile, an early edition stored stats in DBM files, and would do simply massive numbers of increments to entries. On disk, this meant that for a relatively small mail spool, the analysis would take hours.
If you're not part of the solution, you're part of the precipitate.
Posted by polar_bear:
You probably would - and would probably be (quite rightly) annoyed by those responses. Unfortunately, there's a high signal to noise ratio here...
The main reason I chose to respond to the FreeBSD comment is because I've been to quite a few Linux shows and met several of the BSD bigots and find it unbelievable the amount of hostility that they display towards Linux. I think that the BSD projects are great - but they're not for me. But, I'm glad they're out there, I'm happy that they are moving forward and I might even decide to use them someday. I just don't understand why some of the BSD camp feel the need to flame Linux users - I've never seen any Linux user flame someone for using FreeBSD. Ever.
And what is the deal with the Natalie Portman stuff anyway?
Only if I can plug in my FastLoad cartridge - wow! what a difference!
--
"It's tough to be bilingual when you get hit in the head."
Advantage was certainly speed but also more stability. This way it was possible to use settings only during one session. This was usually done having two buttons in the preferences panel: Use and Save. A simple reboot would bring you back to the saved settings. Very useful if you were changing the screen settings and your monitor did not like it.
Personally I think this concept could be interesting for Linux systems in general, perhaps even provide more security since the content /etc would be mostly temporary. A simple reboot would bring you back to the original state. A simple way to defend hackers? Perhaps it is just a stupid idea...
Well I was not able to confirm this, although there is a lot of excellent humour and information, there are only three very brief mentions of MFS in the FreeBSD FAQ and none of them say anything about it resizing itself (although it might be inferrable from the fact that there is no mention of a flag to set it's size.)
I am curious as to what purpose this serves, however. If, as was my impression, FreeBSD has the same sort of dynamic caching that Linux uses, this would only add an extra layer of overhead - and hurt, not help, performance. Any FreeBSD folks want to enlighten me? Is there actually any situation where this is useful, or is it an artifact from a time when the caching algorithm really sucked, or what? ;^)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Since the Linux Router Project runs from ramdisk by default, it's an excellent candidate for this. My app runs like Tripwire, but very often, and detects changes in system files. If such changes occur, it logs it to a logserver and reboots or re-reads the write-protected floppy back into ramdisk. Look mommy, no more trojan horses on poorly secured firewalls!
The app is called Tripwall and the original project site was http://homepages.hack-net.com/code_valley/tripwall , but this is down so I plan to move this to http://cise.ufl.edu/~cl0/tripwall.html.
>How many linux developers right(sic) truly
:^(
:^) The build process kicks ass, but I'm not anywhere close to getting it to work under Linux. I was happy to see, tho, that someone wrote a really simple little Makefile in the "make" dir so I could build the BSD make without writing my own makefile. :^) The build process, tho, is *totally* specific to FreeBSD. OTOH, apparently the GNU utils compile with little prob on other platforms. I've never done it, though, so I really can't comment on that.
:^)
:^( ) then you might have to do some rewriting.
:^(
:^)
>portable apps?
How many *BSD developers write truly portable apps?
Probably the same answer for both Linux and *BSD camps--not nearly enough.
My example is the standard utils like ls, chown, etc., that ship with FreeBSD. It's not because of that "it ain't GNU/Linux" argument, although it was due to that argument that I got the ambition to try this. It was just because I wanted to be able to say that, when I use "ls", it's The Real Thing(TM).
As far as platform-independence of Linux-specific apps, it depends on who wrote it and how they wrote it.
One argument I've heard is that "gee, Linux is just a kernel; FreeBSD is a whole system, and there's only one FreeBSD." Yeah, but there's more than one BSD. If a Linux distro conforms to the filesystem standard, and sticks to what has become fairly standard on other distros, and doesn't contain, say, assembly language code, a proggy will compile (and run) on a good number of distros (and will compile on different platforms.)
This statement pertains only to Linux. For those distros that don't stick to convention, well, they're not very popular so we don't care.
If the proggy comes with a decent "configure" script, there shouldn't be that many problems. If someone goes off half-cocked and writes their own Makefile (believe it or not, that can be a problem
>One shouldn't pretend portability where none
>really exists.
Ooh, I'm impressed; a brash statement without a single example. Thank you, I'm so informed.
It sounds like we're making the same point--you have trouble compiling Linux apps, I have trouble compiling BSD apps.
>The number of times I've had to fix a linux app
>so i could run on Solaris or BSD is very high.
Funny; back when I was taking a system programming course in college, we did our programming projects on Sparc Stations and a SMP SysV machine. When we did the stuff on the Sparc, I had to do everything on one of their stations--my stuff from home wouldn't compile nicely on the Suns.
When it came time to do SysV stuff, though, I had to stop using the Suns and was actually able to do everything at home on a Slackware box--with no code modification whatsoever. This was pretty simple stuff, though, so the argument may not be relevant. Your mileage may vary.
Stating on Slashdot that I like cheese since 1997.
I think you left out one of the main reasons why Amiga users needed RAM disks. Back when I had an A500, it only had the internal floppy drive, and no hard drive. If you had enough RAM to copy your critical system files into a RAM disk, you no longer needed to play the "disk swapping game" whenever you wanted to load a program off of another disk.
This game quickly forced me to buy a second floppy drive -- on the Amiga, you pretty much always needed the system disk in the drive...
Chris
Nothing to do withyour question... but think about the local access studio that i work in that uses the Amiga. Think about how under budget we are.... Heh Heh... -Peace Fergs
- The Ferg webmaster@na.mdc.net
if you have that many httpd requests that it's bogging down your disk subsystem, wtf are you doing running netscape or any web browser on that machine for that matter? i mean, i can see having to use IE occasionally if you're talking about an NT machine, but hard-core servers (such as the ones where the disk is being maxxed out by the httpd) really shouldn't be running something that eats up as much resources as a web browser (well, maybe lynx, but definitely not netscape)...
just my 2 cents...
devon
I think his point was that you wouldn't have any writable media in the machine which would prevent what you're talking about.
Of course the corollary to that is if you could create a ramdisk then you can write to it. So if you leave out ramdisks and all network filesystems - you'd be set. Just log everything remotely via syslog (or something better/custom) and you'd be pretty much defacement proof... won't stop 'em from bringing down the server - and because you're running on ROM you won't be able to fix the problem very quickly so they could just keep performing the same exploit over and over... haha!
I was just thinking the other day how we'd load the old DOS WordPerfect into RAM... it smoked. If I get it to work for the new version for Linux I'll lets ya know :)
~Bout Time for another tea party.®~
Why bother using a ramdisk when the operating system automatically keeps a copy of frequently used data in the cache?
Unmount the cd-rom, and mount something else where the cd-rom used to be.
What you say makes A LOT OF SENSE !
Is there anyone who can tell me how to do such a thing?
Thank you !!
Muchas Gracias, Señor Edward Snowden !
Back about when 2.0 first came out, I set up a firewall for my dad's small office. He didn't have any UPSes, and I didn't want to bother going in to poke the machine if it ever lost power for some reason.
So I rigged it to boot up with a small root partition on a RAMdisk, (~1MB - this was a rather old machine even back then) then mounted everything but /tmp and /var read-only.
It worked like a charm. I could power off the thing without running shutdown and not corrupt any critical files. A LILO switch let me boot up in "regular" r/w mode so I could maintain the system.
I've been using RAMdisks on Linux for some time and still think its a good idea. The sad thing is
that it doesn't help you much and that the caveats
are quite large. The only reason why you'd want to
write things to a RAMdisk is when you are pretty
sure you want to read it again, and probably more than once. The thing is that databases have their own caching mechanisms as well as most other smart programs. You think you want a fast netscape cache ? Use squid on your local box and set the netscape
cache off. I still think RAMdisks are cool, but still am looking for something to use them for.
To get the best of both worlds, it would be very handy if you could use logical volume management (or maybe something simpler) to ensure that the /tmp filesystem started out using RAM disk, then migrated onto a second physical volume on disk.
/tmp filesystem caching to be much more aggressive, using more memory, this would be self-tuning (i.e. expanding to disk when needed) and probably work better all round. Though perhaps a special filesystem would still be needed to avoid writing to disk unless you've run out of RAM.
But perhaps the real issue is filesystem-specific caching parameters - if you could configure the
If you have the RAM, then just pre-read all the files with something like:
/dev/null ...files...
tar cf
Running something like this in a cron process is good to stop important binaries (Communicator, XMMS) being swapped out by your home machine's email daemons while you're out.
How many *BSD developers write truly portable apps? I was answering directly to your statement.
:^(
Truth is most linux most linux distros are not 100% compatible. Whereas if you use FreeBSD there is only one FreeBSD to use. And most of the BSD's share code and its fairly portable between them.
how about redhat jumping the gun so to speak on glibc? That caused and still does cause problems when going between distros.
>One shouldn't pretend portability where none >really exists.
Ooh, I'm impressed; a brash statement without a single example. Thank you, I'm so informed.
Not really, its a simple statement of fact. I never claimed everythin on bsd was totally portable did I? And most linux app developers dont develop very portable code, but there is a large amount of lip service to it. GNU tools will work on most platforms if you use gcc to compile, that is a know fact and im not disputing that. I'm talking about non-GNU tools here.
this space for rent
Back in the day of Quake 1, when every little bit of an edged helped out on your net games, we used to load up all the map files into a RAM disk. That way you'ld be instantly in the level instead of having to wait for the map to load. You'd enter into the game a few seconds faster - which meant a lot when getting the jump on that rocket launcher or red armour :)
WARNING: the following is very Windows/DOS centric
At work we had an old server computer with over 2 gig of RAM. I fiddled around with it for a bit and got Windows 95 to boot, copy itself into a 1 gig RAM disk and run. I had to put an old 1 gig drive into the comp. (Drive D:) temporarily and install windows onto that, then copy that onto the original HDD (C:), rip out D: and put an entry into autoexec.bat that copied the windows dir from C: to D: (which was now the RAM disk).
I measured a total of 0.8% average speed increase (using some god-awful old DOS benchmarker) and the comp. took 23 minutes to boot.
--
- Bob
The Amiga OS did not really have a disk cache.
Basically linux (most modern OSes really) use free ram to buffer files that were recently accessed which is usually better then just simply copying the whole system into ram.
Amiga OS wouldn't do that, making disk access rather slow. On the other side it was usually quite save to just flip the switch on the machine , as long as the floppy wasn't active it was OK since no vital structures were buffered into RAM.
BTW: Copying the whole System into the ramdisk was
somewhat of a brute force approach. There was disk caching software available (only read cache usually), I can dimly remember using it.
Didn't have a hard drive as standard so buffering wasn't really much of an option (though it did do chunking to the floppy which isn't much fun - except for those clever games people who managed to do async read ahead on the floppy - predicting which data they'd likely need next)
Special Relativity: The person in the other queue thinks yours is moving faster.
but you can't unmount root.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
/*
:^)
Truth is most linux most linux distros are not 100% compatible. Whereas if you use FreeBSD there is only one FreeBSD to use. And most of
the BSD's share code and its fairly portable between them.
*/
Oh, come on. That's like me saying, "Gee, when you pick up a CD by the band Metallica, they don't always sound the same. But Pink Floyd's The Wall, now there's a CD that sounds the same no matter where you pick it up!" You're comparing distros built around the Linux kernel to a specific BSD distribution.
That's total bullshit.
I can be assured that, if I build a package for a Linux-Mandrake box on my Linux-Mandrake box, I won't have to port it to someone else's box, unless the other box has been tweeked to the extereme. But here's the kicker: the same is true of FreeBSD. FreeBSD being standardized has to rely on the same thing that, say, a Linux-Mandrake or Debian box has to rely on: it has to rely on the end user leaving their system alone.
>I'm talking about non-GNU tools here.
This is the second or third time I've tried to coerce you into actually *naming* a tool. Please. My only beef was with the fact that I was trying to build the set of BSD tools that come with FreeBSD as a replacement for the GNU tools. It's a pain, but I'm sure it can be done. It's just going to be a matter of finding out what the quirks are in libbsd.a, that's all. I've been told that I should look to either NetBSD or OpenBSD for more portable code. Care to comment?
Stating on Slashdot that I like cheese since 1997.
The one sensible post in the whole lot. Heck, on my machine, if I start Netscape, kill it, and start it again, it re-loads all entirely from memory. Wow. :^)
:^)
Tips for the original "Ask Slashdot" poster:
strip your binaries (man strip)
if you can stand to do so, run a lighter WM if you use X (such as, instead of running KDE or GNOME/Sawfish, use Window Maker with a hacked kde2wm.pl to allow the new KDE format/GNOME format.)
although I don't know if this helps, upx at least frees space on your HD and doesn't have a huge overhead (they claim that there's no overhead, but, come on
If you're a real gearhead, and the boottime on your Linux box drives you nuts, try replacing the SysV-style init with the Slackware-style init (I won't walk you through this; try looking at linux.com., I posted some instructions there.)
I don't remember the command, but it's possible to tune the performance of your IDE drive through Linux.
Stating on Slashdot that I like cheese since 1997.
uhm.. isn't a ram disk quite the opposite of
virtual memory? hit me with the cluestick if i'm wrong...
toodles
stray
Was I the only person to try to copy the c:\ volume image into the D: compressed volume?
Solaris had the concept of 'tmpfs' long ago, all of my Ultra-250 servers have this line in /etc/vfstab:
swap - /tmp tmpfs - yes size=1536m
This means /tmp is handled by the swap partition, but cannot grow to more than 1.5Gb of storage (half of all the swap space). Works like a charm.
Don't ask why I have 3Gb of swap, it's not a pretty story.
I do not deploy Linux. Ever.
Ok here goes:
Tools : gCVS, Mahogany, many many gnome apps, a few windowmaker dock apps like wmnet, wmitime, wmmon, wmmount to name
How portable is that mandrake compiled app to say redhat? That is what I am saying, Linux advocates often say Linux is not fragemented or chaotic when it is both. There is no denying that. You also made my point : if you use FreeBSD you only use one thing. If you use Linux, you need to know what Distro, which kernel, etc... That in and of itself point to linux being fragmented.
I cannot comment fully on OpenBSD or NetBSD so I won't i do know that alot of code has been shared among all three BSD's.
this space for rent