creating /tmp and /var in ramdisk?

[vc]

Could anyone tell me please, of how to go about creating both /tmp and /var directories afresh in a ramdisk at each boot time?

[Bald Brick]

First: you probably don't want an ordinary ramdisk as you can get a virtual filesystem. Have a look at this article: http://www.ibm.com/developerworks/linux/library/l-fs3.html.

Second: to move your /tmp directory to RAM you just have to tick something like "Clear /tmp at boot" in PCC. (I'm translating the GUI text back to English from Swedish, so my version of it may not be exactly right, but you should get the idea.) This option is one of the "advanced" ones on the "Set up boot system" page. Anyway, if you choose to clear /tmp at boot, that is not what the system will do: instead it will store /tmp in RAM, and as a result /tmp will naturally be empty at boot.

We used to be strongly discouraged from ticking this option, but with the amounts of RAM many of us have today it may not be a bad idea.

Are you certain that you want to move all of /var into memory? Then you'll lose everything in /var every time you do a shutdown. And do you have enough RAM?

If you are certain the above IBM article will tell you how to do it.

[vc]

First: you probably don't want an ordinary ramdisk as you can get a virtual filesystem. Have a look at this article: http://www.ibm.com/developerworks/linux/library/l-fs3.html.

Thank you, I'll take a look at that this evening when I get home from work.

Second: to move your /tmp directory to RAM you just have to tick something like "Clear /tmp at boot" in PCC. (I'm translating the GUI text back to English from Swedish, so my version it may not be exactly right, but you should get the idea.) This option is one of the "advanced" ones on the "Set up boot system" page. Anyway, if you choose to clear /tmp at boot, that is not what the system will do: instead it will store /tmp in RAM, and as a result /tmp will naturally be empty at boot.

We used to be strongly discouraged from ticking this option, but with the amounts of RAM many of us have today it may not be a bad idea.

It may likely take some time for operating systems in general to get used to the idea, but given the amount of memory that's sold with even the cheapest of computers these days I see no reason for retaining swapfiles any longer, as the entire OS itself can now run completely in memory.  It's the 21st century already, and operating systems will just have to adjust to that fact if they want to remain relevant.

May I offer a suggestion?  Since the "Clear /tmp at each boot" option is so misunderstood, perhaps it should be renamed to "Move /tmp to RAM" or somelike.

Are you certain that you want to move all of /var into memory? Then you'll lose everything in /var every time you do a shutdown. And do you have enough RAM?

No, I'm not certain at all - that's why I'm going to have to try it, to see what the effects will be.

Thanks!

[Old-Polack]

 I see no reason for retaining swapfiles any longer, as the entire OS itself can now run completely in memory. 

Computers have always run in memory. They may read from, and write to, disks, but the run in memory.

Are you certain that you want to move all of /var into memory? Then you'll lose everything in /var every time you do a shutdown. And do you have enough RAM?

No, I'm not certain at all - that's why I'm going to have to try it, to see what the effects will be.

Thanks!

Most likely disaster. When your installation is borked, and won't run, there will be no logs to check, to see what happened.

[Bald Brick]

I strongly suspect that Old-Polack is right. Moving all of /var into RAM sounds a bit suicidal. But if you decide to do it anyway a report of the last breaths of your system would be most interesting.

[vc]

 I see no reason for retaining swapfiles any longer, as the entire OS itself can now run completely in memory.  

Computers have always run in memory. They may read from, and write to, disks, but the run in memory.

No, I meant like the "load into RAM" option on the live CD, but only from a hard drive or an SSD instead.

Are you certain that you want to move all of /var into memory? Then you'll lose everything in /var every time you do a shutdown. And do you have enough RAM?

No, I'm not certain at all - that's why I'm going to have to try it, to see what the effects will be.

Thanks!

Most likely disaster. When your installation is borked, and won't run, there will be no logs to check, to see what happened.

You're right.  Okay, how about moving only certain portions of /var into RAM instead, then?  I'm guessing that some parts of it at least may be entirely disposable, other parts will be turfable but with some loss of associated functions, and some again would be do-not-touch-ever status - correct?

[Bald Brick]

You're right.  Okay, how about moving only certain portions of /var into RAM instead, then?  I'm guessing that some parts of it at least may be entirely disposable, other parts will be turfable but with some loss of associated functions, and some again would be do-not-touch-ever status - correct?

The two subdirectories that take up most diskspace are often /var/log and /var/cache. The problem is that if /var/cache starts growing it's probably because it's filling up with files that you really want to retain at least for some time. /var/log, on the other hand, is often full of archived log files that could well be deleted, but they are intermixed with fresh log files that are precisely the ones you would like to check when disaster strikes. Apart from that, keeping the old ones that aren't written to in memory would be meaningless: it wouldn't make your system any faster.

Most other subdirectories of /var don't contain enough to make keeping them in RAM interesting.

[vc]

I strongly suspect that Old-Polack is right. Moving all of /var into RAM sounds a bit suicidal. But if you decide to do it anyway a report of the last breaths of your system would be most interesting.

Well, I'll just have to build a system with the same amount of RAM then, to try it - I agree, it could be interesting!

[vc]

The two subdirectories that take up most diskspace are often /var/log and /var/cache. The problem is that if /var/cache starts growing it's probably because it's filling up with files that you really want to save at least for some time.

But it's only a cache, isn't it?  Isn't it released again whenever an app closes?  So, all that would have to be done would be to close all apps properly before rebooting or shutting down - wouldn't that take care of most of it?  But yeah, any installs that require files to be present after rebooting would get hosed - those would be problematic.

/var/log, on the other hand, is often full of archived log files that could well be deleted, but they are intermixed with fresh log files that are precisely the ones you would like to check when disaster strikes.

Log?  "When disaster strikes" is time to stick the emergency USB stick in and reboot from the stick's OS so that the image file can be reloaded into the internal SSD.  /home is safe and away on another drive, so all ends up okay.

[Bald Brick]

The two subdirectories that take up most diskspace are often /var/log and /var/cache. The problem is that if /var/cache starts growing it's probably because it's filling up with files that you really want to save at least for some time.

But it's only a cache, isn't it?  Isn't it released again whenever an app closes?

Not always. If you for instance set up Synaptic to "Leave all downloaded packages in the cache", that is precisely what Synaptic will do: the rpm packages will remain in /var/cache/apt/archives. And files like that are the ones that will fill up /var/cache. The other ones won't take up any space worth considering.

So, all that would have to be done would be to close all apps properly before rebooting or shutting down - wouldn't that take care of most of it?

When it comes to /var/cache the problem isn't that you'd risk losing files that your system needs; it's that you may lose files that you want to retain.

I suppose that my point is that while some files in /var are of vital importance for the system they don't take up very much space. They aren't big enough to be worth moving anywhere. The files that are large enough are the ones that you might want to save. 

But yeah, any installs that require files to be present after rebooting would get hosed - those would be problematic.

On the other hand there won't be very many of those.

/var/log, on the other hand, is often full of archived log files that could well be deleted, but they are intermixed with fresh log files that are precisely the ones you would like to check when disaster strikes.

Log?  "When disaster strikes" is time to stick the emergency USB stick in and reboot from the stick's OS so that the image file can be reloaded into the internal SSD.  /home is safe and away on another drive, so all ends up okay.

Hrmm.

[vc]

Hrmm.

I should clarify.  My wife has my 'ahem' in a bind - some time ago, I bought four 701 EeePCs: one for her, and one for each of her sisters.  None of them are in any sense computer adept, they can barely use Windows.  I have no intention of sticking Windows on those machines though, as three of them are going to end up in the Philippines - aka virus heaven; they'd be crapped within days, and it's not so easy to shoehorn XP Pro into a 4GB EeePC when it does crap out and some local may attempt to "fix" it.  MiniMe 2009.1 is what I'm intending instead, and I'm looking for a way to make it as completely idiot-proof as possible.  As my wife has demonstrated that all they'll ever be using is a few basic apps, I think the goal may be attainable - and I also think that PCLinuxOS is ideal for the task.  I've been looking at others, particularly Puppy and Slax, but I still don't see them as being as usable; overall, KDE 3.5 is in my opinion still the best desktop for someone who's only ever used Windows.

So; a minimalistic install, with /home by itself on an SDHC card (for easy replacement/expansion, and also to keep it out of the way), and a bootable USB stick to automagically re-inject the system back into the Eee when, as you say, "disaster strikes" (ie; some local does attempt to install XP on it, and bricks the machine up?).

Or at least that's my current hallucination - I may harbour yet a few more strange notions, as time moves on.  ;-)

[Ɗα√ϵς§]

You just need a lightweight version:

http://fluxflux.net/fluxflux-eee/index-en.html

[vc]

You just need a lightweight version:

http://fluxflux.net/fluxflux-eee/index-en.html

No, I had a look at it, and that's not what I need at all.  I specified KDE 3.5 for a reason, and MiniMe 2009.1 seems most suited to my purpose.

All I'm really trying to do is tweak it a bit so as to avoid the flashrot problem, and since /tmp and /var are the worst offenders in that regard I was merely looking for a way to move them off the flash.

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.

Both blackbird and old-polack have raised some pretty valid points in response, but I'd still like to try it at least, to actually see for myself what will happen.  Maybe I'm dreaming or perhaps I'm just being stupid, but I won't really know until I try it and since I have plenty of spare computers to try it on there's nothing to lose.

[rogaven]

http://en.wikipedia.org/wiki/TMPFS

I use /tmp as tmpfs

entry fstab -> tmpfs /tmp tmpfs mode=1777 0 0 (50% from RAM)

Code: [Select]

df
tmpfs                 1,4G  5,7M  1,4G   1% /tmp

/var run normal

[Bald Brick]

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.

In my other posts I just tried to explain why moving /var onto any kind of ramdisk or RAM-based filesystem might not be a very good idea, although it may at first appear appealing. By all means, try it, but preferably not on a machine that you use for serious work. It will most probably bork your system. For instance /var/lib is full of files an subdirectories that you'd certainly not want to delete at every shutdown.

Edit:
(Of course, some people never turn off their computers. If you are one of them moving /var into RAM is well worth trying.)