Re: mounting tmpfs (and sysfs) defaultly in sarge?
At Wed, 24 Dec 2003 20:07:04 +0000,
Roger Leigh wrote:
> >> Please make sure that when this is added, you do default to a sensible
> >> size option. For example:
> >>
> >> none /dev/shm tmpfs defaults,size=500M 0 0
> >
> > AFAIK, it's no problem. If we mount tmpfs without size= option,
> > kernel automatically limits a half of real memory size. In addition,
> > memory contents in tmpfs can swap out from memory to HDD. This is one
> > of nice feature of tmpfs. If we would like to avoid this size issue,
> > then we only specify size=1M (or 10M) for posix IPC.
>
> I've just tested this to be sure. It's half core memory.
Exactly.
> > If user specify size option in fstab explicitly, then it's user's
> > fault. /dev/shm is used for posix IPC, not ram based temporary
> > filesystem. If user wants to mount tmpfs for his temporary work, then
> > /dev/shm is not suitable place.
>
> Of course. I use it both on /dev/shm and /tmp. But the user may
> still allocate arbitrarily large amounts using POSIX shm (shm_open()
> et. al.), so users do have the potential to do this if they so choose.
> If e.g. a graphics application decides to share a whacking great
> pixbuf between processes, /dev/shm will be the backing store for that.
We know the same problem allocating large amounts of memory via POSIX
shm; users can also allocate a lot of memory via malloc() or mmap() or
sysv shm, ... if limit is set as unlimited, as you know.
Well, there is one difference between /dev/shm and other memory
allocation method: a user can put files onto /dev/shm, then memory is
consumed.
BTW, think about Solaris /tmp, they use tmpfs for a long time. I
investigated RedHat9, I found they also don't set their default size.
So I don't concern about consuming memory by using /dev/shm.
> >> If you don't specify a default limit, any user can kill the system by
> >> creating a huge file in there. It's much nicer to get ENOSPC than a
> >> kernel panic. The installer could pick a sensible limit based on, for
> >> example, 20% of the combined core+swap size.
> >
> > If system memory is exhausted, then (1) swap (2) OOM Killer (3)
> > ENOSPC. If we see kernel panic, then it's kernel bug.
>
> I [intentionally] killed my system without even so much as a panic(!)
> sometime last year. This was IIRC because I set too high a limit
> without the swap space to back it up. OTOH, this was with an early
> 2.4.x kernel which had other [VM] problems too.
Well, recent 2.4.x and 2.6 (which introduces mempool, and has much VM
improvements) seems more robust under high memory pressure.
> In summary, I think we can live with the default limits for most
> cases. However, for some systems these limits will be either
> 1.) Far too small. (See above--512 MiB /tmp + 2 GiB swap)
> 2.) Too large if > 1 tmpfs filesystem is mounted with default limits,
> with the potential to be exploited to down the system.
>
> (1) is a configuration issue which sysadmins will explicitly set up.
> (2) is a downside to the default limits however. Perhaps imposing
> even smaller default limits on the default size could help here--they
> can always be increased after the initial install.
I currently provide new file /etc/default/tmpfs, which contains:
# tmpfs max limit size for /dev/shm. You can specify tmpfs mount option
# format using this variable. In default, it doesn't specify any variables,
# and kernel automatically set valid upper limit.
TMPFS_SIZE=
System administrator can control /dev/shm size using TMPFS_SIZE
(e.g. TMPFS_SIZE=100m). So your point (1) and (2) can resolve by this
parameter. The reason which I don't fill this TMPFS_SIZE is: it's
difficult to decide the appropriate size.
Regards,
-- gotom
Reply to: