Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a machine with 62GB of RAM, and a trunk that's only 7GB, so I thought I would create a RAM disk and compile there. I am not a Linux expert. I found instructions on the internet to create the RAM disk:

mkfs -q /dev/ram1 8192

but I changed the 8192 to 16777216 in an attempt to allocate 16GB of ram disk.

I got the following error:

mkfs.ext2: Filesystem larger than apparent device size.
Proceed anyway? (y,n) 

At which point I got spooked and bailed.

sudo dmidecode --type 17 | grep Size

shows

8x8192MB + 2048MB = 67584 MB

but du on /dev gives 804K.

Is that the problem? Can I overcome that /dev size?

share|improve this question
7  
Did you try tmpfs? It is a filesystem in RAM, no need for ext2. mount -o size=16G -t tmpfs none /mnt/tmpfs –  t-8ch Feb 27 '13 at 18:17
    
That worked! Thanks! But so far, not much speed-up: I think the tools I'm using to build are still using the regular disk. I'll put more stuff on the ram disk. –  Frank Feb 27 '13 at 18:24
2  
Putting the tools themselves on the ramdisk shouldn't make much difference as the kernel will cache them anyways in ram. –  t-8ch Feb 27 '13 at 18:28
    
I had to create /tmpfs, my /mnt was empty. I did that with sudo mkdir /mnt/tmpfs. Sounds right? Or did that just create a fs on the regular disk?? –  Frank Feb 27 '13 at 18:28
    
Should have worked, you can show active mounts with mount or on new systems with findmnt. –  t-8ch Feb 27 '13 at 18:32
show 18 more comments

4 Answers

The best way to create a ram disk on linux is tmpfs. It's a filesystem living in ram, so there is no need for ext2. You can create a tmpfs of 16Gb size with:

mount -o size=16G -t tmpfs none /mnt/tmpfs
share|improve this answer
    
on my system, with nothing at all in /mnt, it says: ls: cannot access /mnt/tmpfs: No such file or directory mount: mount point /mnt/tmpfs does not exist. Is that something to worry about? If I simply mkdir /mnt/tmpfs, does that defeat the purpose (by creating tmpfs on the regular disk - please no flames, I'm a beginner here). –  Frank Feb 27 '13 at 19:23
3  
You need a mountpoint (directory) as target, so after you created this directory (you can use any directory, existing contents are shadowed) you can mount it with the command from the answer. –  t-8ch Feb 27 '13 at 19:26
add comment

Linux is very efficient in using RAM. There is little surprise that you see little if any speedup with tmpfs. The largest pieces to read into memory (and thus able to slow the process down) are the tools (compiler, assembler, linker), and in a longish make they will be loaded into memory at startup and never leave it. What is left is reading in source (the writing out of the results won't slow you down, unless severely memory constrained). Again, comon header files will stay around, only the user's source will require reading. And that is unlikely to be more than a few megabytes. Creating a large RAMdisk (or even much use of tmpfs) can very well slow things down (by making the build memory constrained, the files on RAMdisk or on tmpfs can not be used directly from there).

share|improve this answer
    
What! How can they not be used directly from there? –  Kazark Feb 28 '13 at 16:08
    
They are in RAM, but not in a format that is directly usable. –  vonbrand Feb 28 '13 at 16:09
1  
Really! How so? (Pardon my slowness.) –  Kazark Feb 28 '13 at 16:34
3  
@Kazark, to handle executables in memory special data structures are used. As RAMdisks and tmpfs aren't in common use to store executables (RAMdisks are a remnant from the good old days of excruciatingly slow floppy disks and such, tmpfs is for stricty temporary data), nobody has considered it important enough to add the required ugly hacks. –  vonbrand Feb 28 '13 at 16:39
1  
I have tried running my rails code from a tmpfs (RAM) filesystem, and I did not see any difference at all. I was really hoping for a noticeable difference but I was disappointed by how awesome linux is. –  Khaja Minhajuddin Mar 4 '13 at 19:25
show 1 more comment

The problem is that the maximum size of a ramdisk, more specifically of size of memory that can be accessed via the ramdisk driver is configured at compiletime, can be overwritten at boottime, but remains fixed once the kernel is loaded into memory. The default value is probably measured in Megabytes. If I recall correctly the memory for a ramdisk is reserved right when the driver is loaded, all ramdisks are the same size and there is are some 16 ramdisks by default. So not even you want a ramdisk size of 16G :-)

As stated in the other answer, tmpfs is what you want to use. Further, you won't win a lot by having your entire OS in a ramdisk/tmpfs. Just copy your builddir to a tmpfs and do your compiling then. You may have to ensure that all temporary results are written to a location thats in the tmpfs as well.

share|improve this answer
    
They don't actually use any memory until you write things to them. The boot time limit is just the limit. Even after filling one you can free the memory back up with blockdev --flushbufs. –  psusi Feb 28 '13 at 13:57
    
@psusi: can you give us more information on that? I can only find statements mentioning that once claimed by the ramdisk memory is never reclaimed, e.g. in Documentation/blockdev/ramdisk.txt in the kernel sources. And on my answer: that file also says the ramdisk grows as memory is consumed so it is not all allocated at once. –  Bananguin Mar 1 '13 at 14:46
    
What sort of information? You run the command and it frees the ram, assuming you don't still have it mounted anyhow. –  psusi Mar 1 '13 at 15:13
    
How do you know that the command does what you say it does? Its man page doesn't confirm that and the documentation in the kernel source tree can be understood to contradict your information. –  Bananguin Mar 1 '13 at 20:40
3  
I read the source code, and verified it by trying it. –  psusi Mar 1 '13 at 20:50
add comment

To make a large ram disk after boot, with no messing around with kernel parameters, this seems to work. Use tmpfs, make a file, mount it via loop, and mount that via a filesystem:

mount -t tmpfs -o size=200M tmpfs temp/
cd temp/
dd if=/dev/zero of=disk.img bs=1M count=199
losetup /dev/loop0 disk.img
mkfs.ext4 /dev/loop0
mount /dev/loop0 temp2/

Probably a bit of performance penalty going through multiple different layers... but at least it works.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.