Re: mounting tmpfs (and sysfs) defaultly in sarge?
GOTO Masanori <gotom@debian.or.jp> writes:
> At Sat, 13 Dec 2003 11:42:45 +0000,
> Roger Leigh wrote:
>> > Tmpfs in Linux kernel 2.4, is formally known as shmfs (posix shared
>> > memory filesystem). It's useful for memory-based filesystem like
>> > Solaris tmpfs. However, if we support new Posix IPC like shm_open(3),
>> > shm_unlink(3), to make debian posix compliant (and like other
>> > distros), it should be mounted on /dev/shm. In the past there were
>> > some discussed, ex:
>> >
>> > http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00706.html
>> >
>> > So I propose:
>> >
>> > - /dev/MAKEDEV should have /dev/shm in "std" entry.
>> > - /etc/fstab should mount /dev/shm (tmpfs) in default.
>>
>> 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.
One flaw in this design: the default is the same how ever many tmpfs
filesystems you mount, and doesn't care about available swap space to
back it up:
[System has 256 MiB core memory, over 2 GiB swap]
# mount | grep tmpfs
none on /tmp type tmpfs (rw,size=500M)
none on /dev/shm type tmpfs (rw)
none on /mnt type tmpfs (rw)
none on /mnt/tmp0 type tmpfs (rw)
none on /mnt/tmp1 type tmpfs (rw)
# df
Filesystem 1K-blocks Used Available Use% Mounted on
[...]
none 512000 8 511992 1% /tmp
none 128240 0 128240 0% /dev/shm
none 128240 0 128240 0% /mnt
none 128240 0 128240 0% /mnt/tmp0
none 128240 0 128240 0% /mnt/tmp1
# dd if=/dev/zero of=/dev/shm/big
# dd if=/dev/zero of=/mnt/big
# dd if=/dev/zero of=/mnt/tmp0/big
# dd if=/dev/zero of=/mnt/tmp1/big
# df
Filesystem 1K-blocks Used Available Use% Mounted on
[...]
none 512000 8 511992 1% /tmp
none 128240 128240 0 100% /dev/shm
none 128240 128240 0 100% /mnt
none 128240 128240 0 100% /mnt/tmp0
none 128240 128240 0 100% /mnt/tmp1
# cat /proc/swaps
Filename Type Size Used Priority
/dev/hda6 partition 529160 0 2
/dev/hda_vg/swap0 partition 2007032 478964 3
If I had a system using the default limits, and mounted /dev/shm and
/tmp without limits, there is the possibility of panicking the
system/OOM killing if there is no swap/too little swap--there's still
all the normal VM usage to account for in addition to tmpfs.
> 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.
>> 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.
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.
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Reply to: