creating /tmp and /var in ramdisk?

[vc]

To return to topic, what I am asking is simply how to create a 1GB ramdisk and move both /tmp and /var into it during bootup.  There's got to be an easy way to at least try that, but I don't have years and years of linux experience so I don't yet have the required howto knowledge.  That's what I'm trying to learn, by asking this question.

Did you look at the IBM article about tmpfs that I gave you a link to in my first post?

The author calls tmpfs "the niftiest RAM-based filesystem I've had the opportunity to meet". He also explains precisely what it does and how to set it up -- which is easy.

Yes I did, and I do thank you for that, 'cuz it does look pretty interesting.  However, I'm still looking to try a ramdisk instead for several reasons: fixed size, block-device 'legacy'-app compatibility, and simplicity.  I feel fairly confident that I can create a ramdisk at boot okay, it's just the moving both /tmp and /var into it that's got me stumped.

[vc]

Okay, now I'm really scratching my head.  I've searched the drive, I've searched the wiki, and I can't find anything at all relating to either grub.conf or ramdisk.  The only traces I see are /dev/ram(x) and /sys/block/ram(x).  I know it's there, but I can't make use of it!

[Bald Brick]

http://www.vanemery.com/Linux/Ramdisk/ramdisk.html
http://www.linuxfocus.org/English/November1999/article124.html

Both articles are quite old. Finding a newer Howto will probably be difficult, as the more modern tmpfs filesystem in most circumstances gives you all the benefits of a ramdisk (with a few extras thrown in) and is easier to set up.

[vc]

Yes, those are exactly the articles I was reading.

So, I just mount two separate tmpfs in rc.local then, one for /tmp and one for /var?  Or do I somehow mount both /tmp and /var to a single tmpfs?  How do I set the size?  I don't want the size to be dynamic, I want it fixed at 1GB exactly.

[Bald Brick]

So I just mount two separate tmpfs in rc.local then, one for /tmp and one for /var?  Or do I somehow mount both /tmp and /var to a single tmpfs?  How do I set the size?  I don't want the size to be dynamic, I want it fixed at 1GB exactly.

You don't have to add anything to rc.local.

You add two lines

Code: [Select]

none /<mountpoint> tmpfs defaults 0 0with different mountpoints to your /etc/fstab and your virtual filesystems will be created and mounted at boot.

When it comes to /tmp you don't even have to do that; just tick a box in PCC. (PCLinuxOS Control Center -> Boot -> Setup a boot system -> Advanced -> Cleanup /tmp at each boot. That will add a line to /etc/fstab that creates a tmpfs for /tmp. See my earlier post.)

To give tmpfs a maximum size of one GB you add the option "size=1g":

Code: [Select]

none /<mountpoint> tmpfs defaults,size=1g 0 0According to the manpage for "mount" the "size is given in bytes, and rounded down to entire pages", but you should be able to give it in gigabytes (by adding a "g") and in kilobytes (by adding a "k").

To change the permissions add "mode=xxxx" where the x's stand for digits between 0 and 7 as in Margarita's example. (See man chmod.)

If you want the size of the filesystem to be fixed, you have to use a traditional ramdisk. A tmpfs partition will never take up more space than needed, but neither will it grow past the specified maximum size.

[vc]

If you want the size of the filesystem to be fixed, you have to use a traditional ramdisk.

Yes.  That's why I was asking how to set up a traditional ramdisk rather than a tmpfs.  Something that effectively partitions the memory, something I can format, something I can actually move both /tmp and /var to completely rather than somehow "mirroring" over top of them in some strange manner that I really don't understand.

Additionally, as quoted directly from the tmpfs article:

"With a single command, your new tmpfs /tmp filesystem is mounted at /tmp, on top of the already-mounted partition, which can no longer be directly accessed. However, while you can't get to the original /tmp, any processes that still have open files on this original filesystem can continue to access them."  (emphasis added).

To me, that sounds like it defeats the entire purpose of preventing flashrot because the original directories are still present on the flash device (thus taking up space) and they are still being accessed (only not by the user).

This should all have been very simple, and easy to try!  Yet now it seems more and more impossible.  So, again: is there any way to create a genuine ramdisk in PCLinuxOS?  And, do I need to create one ramdisk with two directories being moved into it, or two separate ramdisks entirely?

[Bald Brick]

If you want the size of the filesystem to be fixed, you have to use a traditional ramdisk.

Yes.  That's why I was asking how to set up a traditional ramdisk rather than a tmpfs.  Something that effectively partitions the memory,

To all practical purposes creating a tmpfs partition does just that: a virtual partition is created and mounted on a mountpoint. A program like Filelight will report its maximum size as its total size. (Other programs may report only the part that is in use.)

something I can format,

Well, formatting a partition means writing a filesystem to it. As tmpfs is in itself a filesystem it naturally cannot be formatted. It's pre-formatted, so to say.

something I can actually move both /tmp and /var to completely

What makes you believe that you can't? Of course you can. (Whether it's sensible to move /var "completely" into RAM is another question.)

rather than somehow "mirroring" over top of them in some strange manner that I really don't understand.

Here I suspect you have misunderstood one of the points in the IBM article.

Normally, if you mount a partition over a directory that isn't empty, everything in that directory remains on the harddrive but becomes hidden. The only thing you'll see at the mountpoint is the contents of the newly mounted partition.

And historically you have not been able to mount a partition over a directory where another partition is already mounted.

But today you can mount a tmpfs filesystem over a mounted partition. As expected the contents of that partition then becomes invisible -- but nevertheless any programs that have open files on the original partition can continue to access them. Clever, isn't it?

And no mirroring.

This should all have been very simple, and easy to try!  Yet now it seems more and more impossible.

If you aren't interested in the easy solution, then just follow the HOWTOs to the letter and you'll have your ramdisk.

[vc]

We're going in circles.  I can't follow those old HOWTOs "to the letter" because PCLinuxOS no longer has the pertinent files nor directory structure.  How am I supposed to edit a grub.conf that no longer exists?  I've given what I believe are valid reasons for wanting to use a genuine ramdisk, but I guess I'm somehow inept at getting my point across and the result seems nothing but misunderstanding.  I don't want to ever keep any files in /var, unless the system itself does require some of them to be present after a reboot.  I don't know if it does or not; I see warnings and grave doubt, but no specifics.

I don't know what to do now, 'cuz this whole issue seems to be going nowhere and all I'm getting is frustrated.  Maybe I'm just barking up the wrong tree entirely.

[travisN000]

..all you need to do is add the lines to /etc/fstab as mentioned;  shouldn't be a need to mess with grub.

This use to be part of the default fstab for pclinuxos's livecd's, but was discontinued:

Code: [Select]

#
none /tmp tmpfs defaults 0 0

..and if you want, do the same for parts of /var and reboot.

If you are happy with the results and don't want the old directories on your hard drive, boot to a liveOS and remove the un-needed directory content from your HD to free up the space.  ..If it doesn't work, use the liveCD / USB to restore /etc/fstab to it's previous state and you should be none the worse..  I think tmpfs automatically limits total usage to 49% of available RAM (but don't quote me on it..   ).

[vc]

I give up.  Thanks anyhow.

[Bald Brick]

I'll stop going round in circles. I'll just make two points.

"With a single command, your new tmpfs /tmp filesystem is mounted at /tmp, on top of the already-mounted partition, which can no longer be directly accessed. However, while you can't get to the original /tmp, any processes that still have open files on this original filesystem can continue to access them."  (emphasis added).

To me, that sounds like it defeats the entire purpose of preventing flashrot because the original directories are still present on the flash device (thus taking up space) and they are still being accessed (only not by the user).

Normally you would of course empty the directories at the mountpoints before you create your tmpfs. You wouldn't mount a normal partition over a directory that isn't empty either, would you? So in most cases nothing has changed. In some special cases you can now do things you couldn't before.

And if you create your virtual /tmp by ticking the box in PCC there won't be any files in any other /tmp under it.

I don't want to ever keep any files in /var, unless the system itself does require some of them to be present after a reboot.

The /var directory is not primarily intended for temporary files; it's not a secondary /tmp directory. A lot of what is in /var today used to be in /usr, but /var was invented so that /usr on older systems could be on a partition that wasn't writable. The files in /var are files that can grow or change, and hence they must be on a partition programs can write to. But although they are mutable -- or variable -- it doesn't follow that they can always be discarded. Many of them can; some are needed by the system even after a reboot. If you don't believe me, move /var into RAM and see what happens. Or look at the files, one by one.


I see that travisn000 has replied while I was typing, but I'm too tired to edit my post. Going to bed.

[vc]

Okay, so I've learned how to create a proper ramdisk of the size that I need and then format it, successfully - now; could anyone tell me please, of how to incorporate it into the boot process so that directories could be mounted to it during boot time?  Do I need to edit an rc file?  Which one?  For the record: what I've done is to modify my GRUB menu entry to add "ramdisk=1048576"; upon rebooting I then opened up a Konsole and typed:

mkreiserfs -b 512 -f /dev/ram0
mount -t reiserfs /dev/ram0 /tmp

which seemed successful enough; I ended up with a Reiser-formatted 1GB ramdisk that appeared to function normally.  All I need to do now is to find out how to incorporate those two commands into whichever startup script that will initialise that ramdisk before fstab or mtab get processed - is that feasible?

[Artthou]

vc.  I commend you on your pursuit of a solution for this...it would be a neat trick and a good way to learn about what linux does at startup.

I am at work so I don't have a version of PCLinuxOS to take a look at, but it seems like generally the dilemma would be that the commands to create the filesystem (mkreiserfs) are located on...you got it, a filesystem...which need to be mounted by fstab.

So fstab first mounts root, and at that point the commands are accessible to create your filesystem.  I would assume fstab is special in its ability to be processed before root is mounted.  If we could delve into understanding the boot system and how it accomplishes that, then perhaps there would be an opportunity to get the filesystem made earlier than fstab is processed.

Looking at a RHEL5 box, I see /etc/rc.d/rc.sysinit does the mounting of /proc and /sys near the top, then later does all the mounting...some manually, then mounting all local systems with a mount -a.  So there would be your opportunity I think to jump in and make your filesystem and mount it. (right after root is mounted).  

But if you have this file make your filesystem and mount /var and /tmp someplace in there (try different places), do a comparison of the contents of the /var directory when you do this, and when you don't. (copy or tar off the contents for comparison)  This way, you could see if you got it made early enough such that the directories made underneath have any actual data in them, or were still empty when you mounted the ramdisk.  If there is no difference, you are golden.  Whatever your ramdisk (or tmpfs) version is missing, is being written to the prior mounted directory I suppose, doing what you don't want (writing to flash).

I mentioned tmpfs above because you could try this comparison using tmpfs mounts in fstab as well.  If fstab is processed before rc.sysinit, then that might be the preferred method to test.  If you try this, let me know how it goes and I'll be happy to keep thinking with you.

Keep up your hunt...will be rewarding when it works.