Greetings,
Before I get slammed, I've looked all over the internet for the answer to this (googled and more) and haven't been able to find what I'm looking for. Here's what I need. I have a server that I use to hold workstation images. I use a Linux boot CD combined with some scripts I wrote and some disk imaging software to allow me to image windows workstations. Anyway, when I roll out a new workstation Image, I may roll it out to 20 or 30 computers at once, all using the same image file (base build). I want to put that image file on a RAMDISK on my server. The image file is between 3 and 4 gig. I have 6 gig in the server, so plenty of memory. I modified GRUB to increase the size of my ram disk... First I started with a 200mb, that worked group, formatted, etc. Then I tried 1gig - everything looks like it works but when I mount it, it tells me the volume is not formatted or has invalid super blocks. Perhaps I'm exceeding the allowable built-in ramdisk limit, but I couldn't find any docs anywhere that would tell me what that limit was.
Does anyone know of an alternative ramdisk product, that does not load at boot time, where I could do what I need (as described above)? Or does anyone know how I can get a 4-gig Ramdisk to work properly?
I'm running the new CentOS 4 on the server.
Thanks for any help. I did spend 2 days doing Internet research with no results, prior to posting here.
Thanks. Scott
Scott Heisler wrote:
I want to put that image file on a RAMDISK on my server. The image file is between 3 and 4 gig. I have 6 gig in the server, so plenty of memory. I modified GRUB to increase the size of my ram disk... First I started with a 200mb, that worked group, formatted, etc. Then I tried 1gig - everything looks like it works but when I mount it, it tells me the volume is not formatted or has invalid super blocks. Perhaps I'm exceeding the allowable built-in ramdisk limit, but I couldn't find any docs anywhere that would tell me what that limit was.
When you say ramdisk, do you mean ramdisk as in ramsdisk device (hardware) that keeps information accross system reboots and/or power cycles, or ramdisk as in file system that exists only in your server's RAM and is lost each time machine is rebooted? Not clear from your question. You mention having "enough RAM for it in server" (which would imply later), but you also say that you are looking for "device" (which would imply former).
If you are looking for self-contained device, there are many solid state disks (SSD) available on the market. Basically, they look like disk, the "only" difference is instead of having magnetic plates, they store information into internal RAM (either battery backed up, or of the non-volatile type). System sees them as normal IDE/SATA/SCSI/FC drive (depending on the interface), and you don't need to have anything special to access them. The speed is usually limited by interface used and type of memory used (obviously EEPROM based SSD will have much worse write times then DRAM with battery backup based SSD).
If you are looking for solution to use your server's memory as temporary RAM disk (you don't care information being lost when you reboot or power cycle), something like this works nicely:
# mount -t tmpfs -o size=8g none /ramdisk
That would create 8GB memory-based file system. The memory file system uses is swappable. So just make sure free RAM + free swap is larger than 8GB, and you should be fine. Of course, you can create smaller or larger system too. Basically it is the same thing as tmpfs on Solaris systems. I kind of like to mount /tmp this way (of course, with much smaller size, usually 32-128MB, depending on server's needs).
Or you can place it in fstab to have it always available:
none /ramdisk tmpfs size=8g 0 0
Aleksandar Milivojevic wrote:
# mount -t tmpfs -o size=8g none /ramdisk
That would create 8GB memory-based file system. The memory file system uses is swappable. So just make sure free RAM + free swap is larger than 8GB, and you should be fine.
One thing I forgot to mention. tmpfs file system type does not allocate memory upfront. That means it is possible to overcommit. For example, even if you had like 256MB of memory, and 512MB of swap space, system will be happy to create 8GB tmpfs file system for you (try it out, nothing bad is going to happen).
It uses only amount of memory needed to store actual files on the file system. So, if your /ramdisk (or whatever you call it) is empty, (almost) no memory is used. If you put two 100kB files into it, 200kB of memory is dynamically allocated for them. Not enough space in RAM, it goes to swap (or goes to swap if something else needs more memory, just like any other swappable memory region). You delete one of those 100kB files, 100kB is freed and goes back to the system to use for other purpuses. If you run out of RAM and swap, writes to tmpfs will fail just as if it was disk that got full.
On Thu, 2005-03-31 at 09:59 -0600, Aleksandar Milivojevic wrote:
Scott Heisler wrote:
I want to put that image file on a RAMDISK on my server. The image file is between 3 and 4 gig. I have 6 gig in the server, so plenty of memory. I modified GRUB to increase the size of my ram disk... First I started with a 200mb, that worked group, formatted, etc. Then I tried 1gig - everything looks like it works but when I mount it, it tells me the volume is not formatted or has invalid super blocks. Perhaps I'm exceeding the allowable built-in ramdisk limit, but I couldn't find any docs anywhere that would tell me what that limit was.
When you say ramdisk, do you mean ramdisk as in ramsdisk device (hardware) that keeps information accross system reboots and/or power cycles, or ramdisk as in file system that exists only in your server's RAM and is lost each time machine is rebooted? Not clear from your question. You mention having "enough RAM for it in server" (which would imply later), but you also say that you are looking for "device" (which would imply former).
If you are looking for self-contained device, there are many solid state disks (SSD) available on the market. Basically, they look like disk, the "only" difference is instead of having magnetic plates, they store information into internal RAM (either battery backed up, or of the non-volatile type). System sees them as normal IDE/SATA/SCSI/FC drive (depending on the interface), and you don't need to have anything special to access them. The speed is usually limited by interface used and type of memory used (obviously EEPROM based SSD will have much worse write times then DRAM with battery backup based SSD).
If you are looking for solution to use your server's memory as temporary RAM disk (you don't care information being lost when you reboot or power cycle), something like this works nicely:
# mount -t tmpfs -o size=8g none /ramdisk
That would create 8GB memory-based file system. The memory file system uses is swappable. So just make sure free RAM + free swap is larger than 8GB, and you should be fine. Of course, you can create smaller or larger system too. Basically it is the same thing as tmpfs on Solaris systems. I kind of like to mount /tmp this way (of course, with much smaller size, usually 32-128MB, depending on server's needs).
Or you can place it in fstab to have it always available:
none /ramdisk tmpfs size=8g 0 0
---- this is great info and I suppose I might find use for it someday but wouldn't a loop mount from an iso file (the disk image) be better for this purpose?
Craig
Craig White wrote:
this is great info and I suppose I might find use for it someday but wouldn't a loop mount from an iso file (the disk image) be better for this purpose?
It depends on how mounted file system is used.
If you mount read-only (which is the only option with ISO image), than loop mount would work fine too, or even better. If server has enough RAM to cache entire image (and keep it cached), than disk would be accessed only on first read, and subsequent reads would go from cache. Of course, when system needs memory for something else, cache is the first thing thrown out. Same goes if you mount read/write with noatime option and majority of I/O is read with ocasional write.
If you want to write to that file system, and write often (for example, image contains ext3 or vfat file system), and you don't care information being lost after reboot (example would be using it for /tmp), than it is better to use tmpfs. If you have enough free RAM, the information you don't care about will never be written to the disk. In case of loop device, eventually it would. So you save some disk I/O.
In both cases, system will use information from RAM whenever possible, and disk if you get low on free RAM. In both cases, pages with data not accessed for a long time, will be first to go back to disk (or simply marked as free if not changed).
This is basically idea why on Solaris /tmp is mounted as tmpfs by default. On Linux many people argue that files in /tmp "usually" live for short enough time not to be commited to disk anyhow. Which is true for some types of files, and usually those are the files you really care not to have actuall disk I/O. IMO, it never hurts to actually make sure this happens for any type of temporary file by using tmpfs (provided there's enough RAM). There's no performance degradation for using tmpfs (instead of utilizing disk cache), but there is potential benefit.
-
Aleksandar Milivojevic -
Craig White -
Scott Heisler