Hello all :))
I don't know if /dev/shm (mounted with shmfs or the newer tmpfs)
is needed for proper SYSV IPC operation with newer (2.4.16 and newer)
kernel. Anyone can help?
Moreover: I want to move my /tmp from disk to tmpfs for speed (I
make a lot of compiling, so I think it would help). Is this a good
idea? If so, what size can be appropriate for a small system that is
not permanently running?
Thanks a lot for the answers :))
Ra?l
On Sun, 2001-12-16 at 17:02, Ra?lN??ez de Arenas Coronado wrote:
> I don't know if /dev/shm (mounted with shmfs or the newer tmpfs)
> is needed for proper SYSV IPC operation with newer (2.4.16 and newer)
> kernel. Anyone can help?
It is not needed. /dev/shm mounted with tmpfs is only needed for POSIX
shared memory, which is still fairly rare. SysV IPC will work fine.
> Moreover: I want to move my /tmp from disk to tmpfs for speed (I
> make a lot of compiling, so I think it would help). Is this a good
> idea? If so, what size can be appropriate for a small system that is
> not permanently running?
Some say it helps, others don't. Solaris has a similar feature, and it
seems to work for them. However, Linux is light and our page-cache
works well. Not so sure it is ideal.
In other words, if you have memory to spare and the data ought to be
cached, Linux probably will cache it anyhow. On the other hand, if you
have lots of memory to spare, give it a try. Mount /tmp or all of /var
in tmpfs.
It is dynamic, so you don't need to specify a size. If you want to give
a maximum size (probably a good idea), give one. Depends on what your
tmp usages are and how much free memory you have.
Robert Love
Hello Robert :)
>It is not needed. /dev/shm mounted with tmpfs is only needed for POSIX
>shared memory, which is still fairly rare.
That this means that I can mount more than one 'tmpfs' just like
if it's a *real* filesystem? I wasn't sure, since it's implemented
thru the page cache.
>It is dynamic, so you don't need to specify a size.
Yes, I knew, I meant the maximum size. I don't want half of the
RAM occupied just by a programming mistake ;)))
Thanks a lot for your help :)
Ra?l
On Sunday 16 December 2001 17:30, Robert Love wrote:
> In other words, if you have memory to spare and the data ought to be
> cached, Linux probably will cache it anyhow. On the other hand, if you
> have lots of memory to spare, give it a try. Mount /tmp or all of /var
> in tmpfs.
Unfortunately, some(many?) distros are b0rken in re /var/. There is stuff put
there that is needed across boots (for example, mandrake puts the DNS master
files in /var/named.)
>
> It is dynamic, so you don't need to specify a size. If you want to give
> a maximum size (probably a good idea), give one. Depends on what your
> tmp usages are and how much free memory you have.
>
> Robert Love
--
tabris
Sweet is love when all is sane
Sweet is death to rid the pain
Cruel is death when all is well
Cruel is love when all is hell
Author unkown
On Sun, 2001-12-16 at 18:15, Ra?l N??ez de Arenas Coronado wrote:
> Hello Robert :)
>
> >It is not needed. /dev/shm mounted with tmpfs is only needed for POSIX
> >shared memory, which is still fairly rare.
>
> That this means that I can mount more than one 'tmpfs' just like
> if it's a *real* filesystem? I wasn't sure, since it's implemented
> thru the page cache.
Yes, you can mount as many as you like.
> >It is dynamic, so you don't need to specify a size.
>
> Yes, I knew, I meant the maximum size. I don't want half of the
> RAM occupied just by a programming mistake ;)))
Ah, right. Set the size to the minimum of the most RAM you can spare
and the biggest size of your tmp. You can also specify max inode
entries, but size is probably best here. You can pass "size=32m" or
whatever as an option.
See Documentation/filesystems/tmpfs.txt for more information.
Robert Love
Hello Adam :))
>> have lots of memory to spare, give it a try. Mount /tmp or all of /var
>> in tmpfs.
>Unfortunately, some(many?) distros are b0rken in re /var/. There is
>stuff put there that is needed across boots (for example, mandrake
>puts the DNS master files in /var/named.)
Moreover, didn't the LHS say that /var/tmp is supposed to be
maintained across reboots? I'm not sure about this, but anyway /var
is supposed to hold temporary data, not boot-throwable data, isn't
it?
Ra?l
Hi Robert :))
>> if it's a *real* filesystem? I wasn't sure, since it's implemented
>> thru the page cache.
>Yes, you can mount as many as you like.
Ok, then :)))) I'm testing /tmp over tmpfs right now. I don't
notice a great improvement in speed. I have plenty of RAM for my box,
and I think that, just as you said, when I'm compiling the contents
of the /tmp are always cached, no matter if using tmpfs or not.
I'll try with higher loads and more processes trying to fill up
/tmp ;))
>See Documentation/filesystems/tmpfs.txt for more information.
I'm afraid my 2.4.16 doesn't come with that file :((( My fault,
probably, although I don't remember touching the docs :???
Thanks a lot for your help :)
Ra?l
On 16 Dec 2001, Robert Love wrote:
> have lots of memory to spare, give it a try. Mount /tmp or all of /var
> in tmpfs.
What? /var contains things like /var/spool/mail. I _really_ doubt
that mailboxes disappearing after reboot will make anyone happy.
Adam Schrotenboer wrote:
> On Sunday 16 December 2001 17:30, Robert Love wrote:
> > In other words, if you have memory to spare and the data ought to be
> > cached, Linux probably will cache it anyhow. On the other hand, if you
> > have lots of memory to spare, give it a try. Mount /tmp or all of /var
> > in tmpfs.
>
> Unfortunately, some(many?) distros are b0rken in re /var/. There is stuff put
> there that is needed across boots (for example, mandrake puts the DNS master
> files in /var/named.)
It's not just mandrake, it's all linux and in
fact that's where the named data wants to
live -
Not only dns info, but things like mail spool,
system logs, cron files -
And it's not just linux, it's pretty much a unix
thing in general -
Are you really sure you want to blow away
everyone's mail, all your dns records, cron
jobs etc if the system powers down?
cu
jjs
:-> "Robert" == Robert Love <[email protected]> writes:
> See Documentation/filesystems/tmpfs.txt for more information.
There's no such file in my tree... what version are you talking about?
ik5pvx@penny:/usr/src/linux/Documentation/filesystems $ ls
00-INDEX bfs.txt ext2.txt ncpfs.txt smbfs.txt umsdos.txt
Locking coda.txt fat_cvf.txt ntfs.txt sysv-fs.txt vfat.txt
adfs.txt cramfs.txt hpfs.txt proc.txt udf.txt vfs.txt
affs.txt devfs isofs.txt romfs.txt ufs.txt
ik5pvx@penny:/usr/src/linux/Documentation/filesystems $ head ../../Makefile
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 16
EXTRAVERSION =
Pf
--
-------------------------------------------------------------------------------
Pierfrancesco Caci | ik5pvx | mailto:[email protected] - http://gusp.dyndns.org
Firenze - Italia | Office for the Complication of Otherwise Simple Affairs
Linux penny 2.4.16 #1 Fri Nov 30 22:12:51 CET 2001 i686 unknown
On Sunday 16 December 2001 18:37, Ra?l N??ez de Arenas Coronado wrote:
> Hello Adam :))
>
> >> have lots of memory to spare, give it a try. Mount /tmp or all of /var
> >> in tmpfs.
> >
> >Unfortunately, some(many?) distros are b0rken in re /var/. There is
> >stuff put there that is needed across boots (for example, mandrake
> >puts the DNS master files in /var/named.)
Thank you for this correction of my understanding of /var
I now am under the impression that it merely means that /var must be mounted
rw. It is for variables, but not discardable data.
This still means that the concept of a tmpfs /var is _severely_ broken. DON'T
DO IT.
I may be wrong about /tmp as well, but I have come to think that it is data
that ought be discarded after logout, and have sometimes considered writing a
script for it in the login/logout scripts.
>
> Moreover, didn't the LHS say that /var/tmp is supposed to be
> maintained across reboots? I'm not sure about this, but anyway /var
> is supposed to hold temporary data, not boot-throwable data, isn't
> it?
>
> Ra?l
--
tabris
Once I swore I would die for you, but I never meant like this.
Shame, by Stabbing Westward
On December 16, 2001 15:47, Adam Schrotenboer wrote:
> I may be wrong about /tmp as well, but I have come to think that it is data
> that ought be discarded after logout, and have sometimes considered writing
> a script for it in the login/logout scripts.
System daemons can legally use /tmp, and they may not apprechiate having
their files removed from underneath them everytime someone telnets in. ;)
-Ryan
On Sunday 16 December 2001 18:56, Ryan Cumming wrote:
> On December 16, 2001 15:47, Adam Schrotenboer wrote:
> > I may be wrong about /tmp as well, but I have come to think that it is
> > data that ought be discarded after logout, and have sometimes considered
> > writing a script for it in the login/logout scripts.
>
> System daemons can legally use /tmp, and they may not apprechiate having
> their files removed from underneath them everytime someone telnets in. ;)
Definite pt. So maybe make mortal users use $HOME/tmp. and that could be
mounted at login and umounted at logout. Or, rm only the files that the user
owns.
>
> -Ryan
--
tabris
"I wanted to see exotic Vietnam, the jewel of Southeast Asia. I wanted
to meet interesting and stimulating people of an ancient culture...
and kill them."
Joker, "Full Metal Jacket"
Followup to: <E16Fl8j-0000nA-00@phalynx>
By author: Ryan Cumming <[email protected]>
In newsgroup: linux.dev.kernel
>
> On December 16, 2001 15:47, Adam Schrotenboer wrote:
> > I may be wrong about /tmp as well, but I have come to think that it is data
> > that ought be discarded after logout, and have sometimes considered writing
> > a script for it in the login/logout scripts.
>
> System daemons can legally use /tmp, and they may not apprechiate having
> their files removed from underneath them everytime someone telnets in. ;)
>
Not to mention when you kill a secondary session. It's bogus.
However, discarding /tmp on *REBOOT* is legitimate.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
I delete all files in /tmp on reboot +
I delete all of <user>'s files in /tmp if <user> has no running
processes when <user> logs out.
>>> "H. Peter Anvin" <[email protected]> 12/16/01 09:26PM >>>
Followup to: <E16Fl8j-0000nA-00@phalynx>
By author: Ryan Cumming <[email protected]>
In newsgroup: linux.dev.kernel
>
> On December 16, 2001 15:47, Adam Schrotenboer wrote:
> > I may be wrong about /tmp as well, but I have come to think that it
is data
> > that ought be discarded after logout, and have sometimes considered
writing
> > a script for it in the login/logout scripts.
>
> System daemons can legally use /tmp, and they may not apprechiate
having
> their files removed from underneath them everytime someone telnets
in. ;)
>
Not to mention when you kill a secondary session. It's bogus.
However, discarding /tmp on *REBOOT* is legitimate.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Hi Ra?lN??ez,
On Mon, 17 Dec 2001, Ra?lN??ez de Arenas Coronado wrote:
> Hello Robert :)
>
>>It is not needed. /dev/shm mounted with tmpfs is only needed for
>>POSIX shared memory, which is still fairly rare.
>
> That this means that I can mount more than one 'tmpfs' just like
> if it's a *real* filesystem? I wasn't sure, since it's implemented
> thru the page cache.
Yes, every single mount is an independant tree.
>>It is dynamic, so you don't need to specify a size.
>
> Yes, I knew, I meant the maximum size. I don't want half of the
> RAM occupied just by a programming mistake ;)))
What I like most about /tmp in tmpfs is the ability to resize on the
fly: I have a big swap partition and a reasonable limit for /tmp and
/var/tmp.
When one of these gets full I can either stop the affending job or
increase the limit: If there is swap left I can simply increase the
limit. If swap is full I add a swap file on a real filesystem and
increase the limit.
Greetings
Christoph
P.S: Documentation/filesystems/tmpfs.txt is in the 2.4.17-rc patch.
In linux-kernel, Pierfrancesco Caci <[email protected]> wrote:
> :-> "Robert" == Robert Love <[email protected]> writes:
> > See Documentation/filesystems/tmpfs.txt for more information.
> There's no such file in my tree... what version are you talking about?
I last saw this file in 2.4-ac - maybe it got lost somewhere....
There is quite a bit of help in Documentation/Configure.help though.
--
Nick Craig-Wood
[email protected]
Hi Christoph :)
>> Yes, I knew, I meant the maximum size. I don't want half of the
>> RAM occupied just by a programming mistake ;)))
>What I like most about /tmp in tmpfs is the ability to resize on the
>fly
[...]
>When one of these gets full I can either stop the affending job or
>increase the limit
That's one of my doubts: if the available RAM decreases then the
buffer (disk) cache will do too. So, if I have /tmp mounted with
tmpfs, the contents here will be cached no matter the available RAM,
or am I completely wrong?
Ra?l
Hi Ra?l,
On Mon, 17 Dec 2001, RaXl NXXez de Arenas Coronado wrote:
>>When one of these gets full I can either stop the affending job or
>>increase the limit
>
> That's one of my doubts: if the available RAM decreases then the
> buffer (disk) cache will do too. So, if I have /tmp mounted with
> tmpfs, the contents here will be cached no matter the available RAM,
> or am I completely wrong?
No, it will be swapped out.
Greetings
Christoph
Alexander Viro wrote:
> On 16 Dec 2001, Robert Love wrote:
> > have lots of memory to spare, give it a try. Mount /tmp or all of /var
> > in tmpfs.
>
> What? /var contains things like /var/spool/mail. I _really_ doubt
> that mailboxes disappearing after reboot will make anyone happy.
The original impetus for separating /var from /usr was not that stuff
in /var is temporary, but that anything that the system has to write
to in the course of normal operation goes there... that was so that
/usr could be a filesystem that was shared by many machines (i.e.
NFS mount for diskless workstations, etc.) /var is for data that is
"variable" from machine to machine, so that /usr can be "constant".
:j
--
J?rgen Botz | While differing widely in the various
[email protected] | little bits we know, in our infinite
| ignorance we are all equal. -Karl Popper
On Mon, 17 Dec 2001, Ra?lN??ez de Arenas Coronado wrote:
> Hello Adam :))
>
> >> have lots of memory to spare, give it a try. Mount /tmp or all of /var
> >> in tmpfs.
> >Unfortunately, some(many?) distros are b0rken in re /var/. There is
> >stuff put there that is needed across boots (for example, mandrake
> >puts the DNS master files in /var/named.)
>
> Moreover, didn't the LHS say that /var/tmp is supposed to be
> maintained across reboots? I'm not sure about this, but anyway /var
> is supposed to hold temporary data, not boot-throwable data, isn't
> it?
yes, just think to sysstem logs...
>
> Ra?l
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>