A big tmp with small memory

[Moose On The Loose]

This only applies to the case where a puppy that is operating from RAM needs to make a really huge file that will not be needed for the long term. It is a way to make /tmp be a directory on a hard drive instead of being in RAM.

I have only tried this on 4.31 but it should work on all puppy systems

1)
Mount a hard disk and make a directory on it to serve as the new
tmp for your system.
Lets say it is /mnt/sda1/BigTmp

2)
Bring up a terminal and do the following command:

Code: Select all

cd /
mv tmp tmpold ; ln -s /mnt/sda1/BigTmp tmp

3)
Now hit the ctrl-alt-backspace to force the Xorg to restart and get over the fact that you pulled the rug out from under it for a moment.


Once this is done, it appears that puppy will operate from RAM even if you make a very huge file. That is everything of puppy except the /tmp directory remains in RAM. Only the /tmp is moved to a hard disk.

[bigpup]

The tmp directory is a temporary place for files to be written and stored.
Many programs use tmp, for just what it sounds like, a temporary storage location.
It normally gets emptied when you shutdown or reboot.
It has no effect on memory use.

A swap file or swap partition are used to aid memory use.
They act as a added storage area for memory. A quick access location.

[Shep]

I have only tried this on 4.31 but it should work on all puppy systems

I think you will mange to confuse readers here, Moose. You start off by, it seems, endorsing the idea of moving the directory for temporary files (a scratchpad directory I like to think of it) to the hard drive, especially when the system is running with restricted RAM. Otherwise, some of that RAM will be squandered for /tmp when it could be better used for processing, etc., and the space available for files in /tmp will be small.

Then you provide what seems like the appropriate way to go about it by creating a link to a directory on the hard drive. Finally, you sum up the idea as:

Once this is done, it appears that puppy will run out of RAM even if you make a very huge file.

Is there a crucial not missing from here? I think you mean to say that puppy can be now work with tmp files larger even than the available RAM because with your construct these tmp files are no longer being stored in RAM? N'est ce pas?

Operation may slow down for some applications, because storing and retrieving from the HDD will be slower than from RAM, but all things considered, including disk buffering, the differences may go unnoticed.

Once you clear up the ambiguity, this will be a useful posting.

To elaborate, when viewing youtube videos, I notice that the media player stores a copy of the video file in the /tmp directory, so someone operating with restricted RAM will soon find there is a limit to the size of the video that they can view before /tmp fills up, unless they follow your suggestion of moving /tmp out of RAM and onto a larger capacity drive.

I haven't tried this myself, but I am wondering whether there is a need to take deliberate steps to clear the /tmp directory at shutdown (or startup)? When /tmp is in volatile RAM it can simply overlooked when creating the savefile, but when linked to non-volatile memory, maybe you need to clear it explicitly?

[Bruce B]

After moving to Lupu 5.20, I noticed /tmp is not used as a directory,
rather as a mount point. (Frugal install on hard disk)

Input:

mount | grep /tmp

And mount outputs:

tmpfs on /tmp type tmpfs (rw,relatime,size=134346472k)

~

[Moose On The Loose]

The tmp directory is a temporary place for files to be written and stored.
Many programs use tmp, for just what it sounds like, a temporary storage location.
It normally gets emptied when you shutdown or reboot.
It has no effect on memory use.

A swap file or swap partition are used to aid memory use.
They act as a added storage area for memory. A quick access location.

If you do as I suggest, the files in /tmp will not be in RAM or in the swap space. If you are going to put something huge into /tmp even just for a few minutes, you can run out of space if /tmp is in fact in RAM.

[Moose On The Loose]

I have only tried this on 4.31 but it should work on all puppy systems

I think you will mange to confuse readers here,

Yes it appears that I did manage to confuse at least one. I had assumed that there would be no need to explain the meaning of the title since it seemed so obvious to me but just in case others are reading along and not getting it.

If you want to make a file that is perhaps as big at 10G in /tmp because perhaps you are converting video from one format to another by converting it to DVD format as an intermediate step, you can't do it while running out of a smallish RAM.

If you follow my suggestion, you can then do the operation using the hard disk space.

Then you provide what seems like the appropriate way to go about it by creating a link to a directory on the hard drive. Finally, you sum up the idea as:

Once this is done, it appears that puppy will run out of RAM even if you make a very huge file.

Is there a crucial not missing from here? I think you mean to say that puppy can be now work with tmp files larger even than the available RAM because with your construct these tmp files are no longer being stored in RAM? N'est ce pas?

No the "not" is not the issue here. It is that I intended to mean that puppy is running out of RAM other than the /tmp and the huge file you are working with.

Operation may slow down for some applications, because storing and retrieving from the HDD will be slower than from RAM, but all things considered, including disk buffering, the differences may go unnoticed.

Yes, the HDD is slower than RAM but it may be the best you can do when the file is really huge.

Once you clear up the ambiguity, this will be a useful posting.

To elaborate, when viewing youtube videos, I notice that the media player stores a copy of the video file in the /tmp directory, so someone operating with restricted RAM will soon find there is a limit to the size of the video that they can view before /tmp fills up, unless they follow your suggestion of moving /tmp out of RAM and onto a larger capacity drive.

I haven't tried this myself, but I am wondering whether there is a need to take deliberate steps to clear the /tmp directory at shutdown (or startup)? When /tmp is in volatile RAM it can simply overlooked when creating the savefile, but when linked to non-volatile memory, maybe you need to clear it explicitly?

I didn't think of that but when I checked, the directory I used is now empty. Perhaps as puppy shuts down, it deletes the files.

[Shep]

Yes it appears that I did manage to confuse at least one.

Probably many more than one, now that I have deciphered the problem. We are speaking different languages .

When running out of RAM, having a huge file in tmp can be trouble

I read this as a warning.

I had assumed that there would be no need to explain the meaning of the title

There is, but for a reason which you may not have foreseen.

When I read "running out of RAM" I interpreted it in the same vein as "running low on RAM" meaning needing more RAM than is available. Having puzzled over your clarification and gained no clarity, and re-read it 7 times with no better understanding, a light bulb clicked and I suddenly realized what you mean by "running out of RAM". That would be a frugal install, wouldn't it? Nothing whatever to do with "encountering RAM limits".

Once this is done, it appears that puppy will run out of RAM even if you make a very huge file.

You can see why I imagined you were missing a crucial "not". And why I was then doubly perplexed when you said you weren't.

It's crazy just how easy it is to get seriously derailed by differences in idioms. But all sorted now.

[Béèm]

Moose,
Your title is absolutely unclear.
I still don't get if you are giving advice, like a how to do things, or if you have a problem.

Please rephrase your title to reflect what your issue is.

[rcrsn51]

I was confused too. If the phrase "running out of RAM" was replaced with "working out of RAM", the intent might be more obvious.

[technosaurus]

If you have a low RAM system, you should do a full install. It will solve this problem and many others.

[Bruce B]

Mount gives me this

Code: Select all

tmpfs on /tmp type tmpfs (rw,relatime,size=134346472k)

The size is determined by calculations in init. This is what I get with
512MB RAM. A person can edit init and modify the size.

If the size is exceeded, it writes to the hard disk paging device. It seems
to me, the way Barry has it, it's the best of two worlds.

~

[Moose On The Loose]

When I read "running out of RAM" I interpreted it in the same vein as "running low on RAM".

Ok I went back and made an edit to use the phrase "operating from". Yes for some reason because I knew what I meant, I could not see the other meaning when doing the proof read. With the new term. I think it is now clear, bet then I thought it was clear earlier too so what do I know about clear.


BTW: I was running from a CD at the time. Not installed at all. Normally I run as a full install. I tend to reboot to the live CD version to test any *.pets I make. (I can't share the *.pets as they are collections of business related things)

[Moose On The Loose]

I was confused too. If the phrase "running out of RAM" was replaced with "working out of RAM", the intent might be more obvious.

I elected to use "operating from" to completely avoid the "out of" as part of the phrase. Hopefully it is now totally clear. Or is it

[Béèm]

Moose,

I don't see any change so I still don't get it.
You didn't edit the subject of your initial post.
Are you giving advice (how to do)?
Are you giving a warning?
Are you having an issue and are you requesting advice?

[Bruce B]

/tmp doesn't want to unmount or move.

Code: Select all

-rw-r--r-- 1 root root 22965 2011-05-17 07:59 bootkernel.log
-rw-r--r-- 1 root root  1232 2011-05-17 07:59 bootsysinit.log
drwx------ 2 root root    40 2011-05-18 07:13 mc-root/
drwx------ 2 spot spot    80 2011-05-18 07:03 orbit-spot/
-rw-r--r-- 1 root root  1878 2011-05-17 07:59 pup_event_backend_modprobe_protect.log
prw-r--r-- 1 root root     0 2011-05-17 07:59 pup_event_backend_modprobe_protect_pipe|
-rw-r--r-- 1 root root     0 2011-05-18 07:01 pup_event_frontend_d_curpos.log
-rw-r--r-- 1 root root   576 2011-05-17 07:59 pup_event_modprobe.conf
-rw-r--r-- 1 root root  1679 2011-05-17 07:59 pup_event_module_devpath_log
-rw-r--r-- 1 root root  9581 2011-05-18 07:01 udevtrace.log
-rw-r--r-- 1 root root  6044 2011-05-17 07:59 udevtrace-modem.log
-rw-r--r-- 1 root root  1302 2011-05-18 07:01 xerrs.log

/sbin/pup_event_backend_modprobe_protect --daemon, seems to
be what is primarily using /tmp and keeping it from being worked
with.

~

[rcrsn51]

tmpfs on /tmp type tmpfs (rw,relatime,size=134346472k)

How do you interpret that number? By my calculations, it's 134 GB!

[Bruce B]

tmpfs on /tmp type tmpfs (rw,relatime,size=134346472k)

How do you interpret that number? By my calculations, it's 134 GB!

I wish you hadn't asked, cause I had the same thoughts.

It is a copy and paste from the mount output.

But then on closer inspection, df says:

Code: Select all

Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 129G   72K  129G   1% /tmp

OK, get jealous, I have a lot of RAM.

Not really, I know what I did. I made this directory /tmp and that's all
I did. I think I'll delete it before next reboot.

~

[Shep]

I was confused too. If the phrase "running out of RAM" was replaced with "working out of RAM", the intent might be more obvious.

This being the beginners forum--probably not a jot clearer.

[Béèm]

Yes Bruce, I found also that /tmp couldn't be unmounted.
Now i know why.
Maybe 4.3.1 didn't have pup_event yet. I can't remember.
And so it did work for Moose.

[Moose On The Loose]

Moose,
Your title is absolutely unclear.
I still don't get if you are giving advice, like a how to do things, or if you have a problem.

Please rephrase your title to reflect what your issue is.

I edited the body so that the meaning is clear. It is how to do something. Go back and read the new version. You may be seeing one from your browser's cache.