FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-13-2011, 09:02 AM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 10:29:16AM +0200, Stig Sandbeck Mathisen wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
>
> > One reason for doing this is to have a single writable mount on the
> > system, which might be useful for tiny systems with minimal resources,
> > where root is r/o. On such a system, it might be useful to pool the
> > limited writable space (which might not be a tmpfs).
>
> Could this case be handled better by the fsprotect package?

It's a nice idea, but for a somewhat different purpose. This is
overlaying the read-only root with a writable overlay. Where I'd
like to get to is a purely read-only setup where nothing is writing
to e.g. /etc. fsprotect could be considered to be working around
deficiencies with our current situation, where I would like to
fix the underlying problems making an aufs overlay necessary in the
first place.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-13-2011, 09:32 AM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
> On Mon, Apr 11, 2011 at 08:01:42PM +0100, Roger Leigh wrote:
> > With the transition to /run and /run/lock as tmpfs filesystems, it
> > would be desirable to provide sensible default size limits. Currently,
> > we default to the tmpfs default of RAM. But with several tmpfs
> > filesystems, this does have the potential for the system to be OOMed
> > by a user filling up more than one of the filesystems. A sensible
> > default size limit would be useful here, for at least some of the
> > filesystems.
> >
> > We currently allow specification of size limits for:
> > /run (RUN_SIZE)
> > /run/lock (LOCK_SIZE, optional)
> > /dev/shm (SHM_SIZE)
> > /tmp (TMP_SIZE, optional)
> >
> > [from temporary git repo at http://git.debian.org/?p=collab-maint/sysvinit;a=summary]
> >
> > In order to default to a sensible size, I would appreciate it if I
> > could have some figures for the useage of these filesystems: e.g.
> >
> > % sudo du -sk /var/run /var/lock /dev/shm
>
> OK, some results:
>
> /var/run /var/lock /dev/shm
> Min 9 0 0
> 5% percentile 60 0 0
> Mean 886 9 599
> Median 120 8 0
> 95% percentile 612 17 310
> Max 47696 52 80744

Following the discussion yesterday, I'd like to propose doing
something like the example below. It's possible to size a tmpfs
as a percentage of core memory, the default being -o size=50%.
Rather than setting an absolute value, we can size e.g. /run
as a percentage of total memory, which should scale with /run
usage better than a fixed value.

Proposal:
Switch the default for all tmpfs mounts from 50% to 20%; it's
still very large, but you have to mount many more to be able to
break your system.
/run: Use 10% core. This gives 102MiB on 1GiB system; the largest
observed user used 50MiB. Even a system with 512MiB would not have
hit the observed maximum, and that was a very large system with
presumably more memory than this.
/run/lock and /lib/init/rw: 5MiB each. More than plenty, but far
less than current usage.
/run/shm: No default (use general tmpfs default of 20%)
/tmp: No default (use general tmpfs default of 20%)


Regards,
Roger


-----------------------------------------------------------------------
[/etc/default/tmpfs]

# Defaults for tmpfs filesystems mounted in early boot, before
# filesystems from /etc/fstab are mounted.
#
# _SIZE variables are the maximum size (in bytes) that tmpfs
# filesystems can use. The size will be rounded down to a multiple of
# the page size, 4096 bytes. If no size is set, TMPFS_SIZE will be
# used as the default. _MODE variables are the initial access
# permissions for the root of the tmpfs mount. If no mode is set,
# TMPFS_MODE will be used as the default.

# TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
# size is provided. If no value is provided here, the kernel default
# will be used.
TMPFS_SIZE=20%
TMPFS_MODE=755

# RUN_SIZE: maximum size of /run (/var/run)
#
# Defaults to 10% core memory; the size required varies widely
# depending upon the demands of the software being run; this heuristic
# scales /run usage on system size. Samba in particular has been seen
# to use at least 50MiB in a large heavily used server. Typical usage
# is hundreds of KiB, maximum is tens of MiB.
RUN_SIZE=10%
RUN_MODE=755

# LOCK_SIZE: maximum size of /run/lock (/var/lock)
#
# Typical usage: tens of KiB; maximum hundreds of KiB. Default of
# 5MiB should ensure the limit is never reached.
LOCK_SIZE=5242880 # 5MiB
LOCK_MODE=1777

# SHM_SIZE: maximum size of /run/shm (/dev/shm)
#
# No default size; the size required varies widely depending upon the
# demands of the software being run.
SHM_SIZE=
SHM_MODE=1777

# TMP_SIZE: maximum size of /tmp
#
# No default size.
TMP_SIZE=
TMP_MODE=1777

# RW_SIZE: maximum size of /lib/init/rw
#
# Note /lib/init/rw is deprecated and programs using is are migrating
# to use /run. It will be removed once all users have migrated to
# /run.
# Typical usage: tens of KiB. Default of 5MiB should ensure the limit
# is never reached.
RW_SIZE=5242880 # 5 MiB
RW_MODE=755


--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-13-2011, 09:51 AM
Philip Hands
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl <biebl@debian.org> wrote:
> Am 12.04.2011 13:38, schrieb Roger Leigh:
>
> > this for /var/lock (/run/lock), which can be mounted as a separate
> > tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS. We could
> > also do the same for /dev/shm (/run/shm) and /tmp (/run/tmp) as well.
> > In the case of /tmp this would not be the default except when root is
> > read-only.
>
> I don't think symlinking /tmp to /run would be a good idea, as one could fill up
> /tmp (accidentaly) pretty quick.
> If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea
> to me.

While were about this, for installs where the users select multiple
partitions we currently create a separate /tmp partition.

This strikes me as suboptimal, since one could use the disk space
allocated to /tmp as extra swap and then allocate a tmpfs of that size
to be mounted on /tmp with no effect other than allowing the system to
have access to more swap than it would have otherwise had (of course,
that's probably more than it needs, so instead you could just save some
disk space that would otherwise be left generally unused by overloading
the swap usage with /tmp usage.

Therefore, in the multi-partition setup, I think we should also default
to having /tmp on tmpfs.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
 
Old 04-13-2011, 10:10 AM
Thomas Hood
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

First of all, thanks to Roger Leigh for leading this effort.

Roger Leigh wrote:
> Proposal:
> Switch the default for all tmpfs mounts from 50% to 20%; it's
> still very large, but you have to mount many more to be able to
> break your system.


He should have said "... but you have to mount *and fill* many more
to be able to break your system."

The current tmpfs size of 50% suffices to protect the system should
any *one* tmpfs be completely filled by a wayward process. Is that
not good enough? I.e., do we really need to worry about the case
where multiple tmpfses get filled simultaneously?

Does it matter whether the system fails due to filesystem full or
due to OOM? Broken is broken.

If we do need to worry about that case then the real solution is
not arbitrarily to increase the number-of-tmpfses-to-fill-up-in-
order-to-break-the-system from 2 to 5. One real solution is to
limit the total amount of memory that all tmpfses can take up to
some value less than 100%. Another is to look more closely at which
tmpfses could reasonably be attacked and limit the sum of *their*
sizes to something less than 100%.
--
Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DA576B3.7010703@gmail.com">http://lists.debian.org/4DA576B3.7010703@gmail.com
 
Old 04-13-2011, 11:13 AM
Bastian Blank
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 09:30:53PM +0200, Jan Hauke Rahm wrote:
> On Tue, Apr 12, 2011 at 08:21:25PM +0100, Roger Leigh wrote:
> > I know little about vservers. How do they currently deal with
> > /dev/shm and /lib/init/rw?
> Interesting question. Actually, in my setup, I don't see /dev/shm at
> all and /lib/init/rw is a regular directory.

They don't. / is writable.

Bastian

--
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110413111310.GA29185@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20110413111310.GA29185@wavehammer.waldi.eu.org
 
Old 04-13-2011, 11:23 AM
Adam Borowski
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
> On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl <biebl@debian.org> wrote:
> > I don't think symlinking /tmp to /run would be a good idea, as one could fill up
> > /tmp (accidentaly) pretty quick.
> > If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea
> > to me.
>
> While were about this, for installs where the users select multiple
> partitions we currently create a separate /tmp partition.
>
> This strikes me as suboptimal, since one could use the disk space
> allocated to /tmp as extra swap and then allocate a tmpfs of that size
> to be mounted on /tmp with no effect other than allowing the system to
> have access to more swap than it would have otherwise had (of course,
> that's probably more than it needs, so instead you could just save some
> disk space that would otherwise be left generally unused by overloading
> the swap usage with /tmp usage.
>
> Therefore, in the multi-partition setup, I think we should also default
> to having /tmp on tmpfs.

Sounds like a great idea. I'd extend it to any setups with a swap.

Tmpfs is a lot faster than regular filesystems: it doesn't have to care
about preserving the data's integrity after a crash and thus has no
barriers, journaling, fsync(). When there's plenty of unused memory, the
data will not ever touch the disk, too -- gracefully getting written out
when there is a better use for memory it takes. Since most files in /tmp/
are very short lived, it's a good optimization.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 04-13-2011, 12:26 PM
Ben Hutchings
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
> * Philip Hands <phil@hands.com> [110413 12:54]:
> > This strikes me as suboptimal, since one could use the disk space
> > allocated to /tmp as extra swap and then allocate a tmpfs of that size
> > to be mounted on /tmp with no effect other than allowing the system to
> > have access to more swap than it would have otherwise had (of course,
> > that's probably more than it needs, so instead you could just save some
> > disk space that would otherwise be left generally unused by overloading
> > the swap usage with /tmp usage.
> >
> > Therefore, in the multi-partition setup, I think we should also default
> > to having /tmp on tmpfs.
>
> This has both the disadvantage of a system then having swap (given the
> big memory sizes one currently has and the big difference between RAM
> and disk access times, having swap is often quite a disadvantage)
[...]

Under Linux, swap space is a requirement to defragment RAM. (This may
change in the future.) Without swap space, the kernel eventually
becomes unable to make large physically-contiguous allocations. Don't
turn it off.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-13-2011, 01:19 PM
Philip Hands
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, 13 Apr 2011 13:34:13 +0200, "Bernhard R. Link" <brlink@debian.org> wrote:
> * Philip Hands <phil@hands.com> [110413 12:54]:
> > This strikes me as suboptimal, since one could use the disk space
> > allocated to /tmp as extra swap and then allocate a tmpfs of that size
> > to be mounted on /tmp with no effect other than allowing the system to
> > have access to more swap than it would have otherwise had (of course,
> > that's probably more than it needs, so instead you could just save some
> > disk space that would otherwise be left generally unused by overloading
> > the swap usage with /tmp usage.
> >
> > Therefore, in the multi-partition setup, I think we should also default
> > to having /tmp on tmpfs.
>
> This has both the disadvantage of a system then having swap (given the
> big memory sizes one currently has and the big difference between RAM
> and disk access times, having swap is often quite a disadvantage) and

Are you suggesting that a system that has enough RAM to not need swap
will become slower if you enable swap but don't use it?

If not, then either the files in /tmp will sit in RAM and therefore be a
lot faster, or if they need to go to disk, will have been staged via
swap, which may well allow a lot of small writes to small files to be
coalesced into larger swap writes, although I'm not familiar enough with
that to compare the amount of disk activity provoked by writing a lot of
small files onto an ext3 file system vs. taking the most elderly data
From a tmpfs and deciding to swap it out.

I can imagine that, for instance, removing a large file from /tmp when
on a file system might well require several writes, whereas it seems
possible that doing the same for a swapped out tmpfs might be a case of
simply recording that the blocks are ready for reuse. On the other
hand, it may be that one needs to read in each and every block in order
to mark it ad being deleted, but I would hope that's not the way it works.

> of mixing several different things (/tmp is usually something simply
> filling over time,

Really? Checking a couple of servers at random, one that's been running
for about 8 months but is fairly tightly locked down, has 8Kb used, and
another that's got rather more random stuff running on it, it has 17Mb
in /tmp, and that turns out to be debris laying around after a process
that does OCR on postfix files while scanning for SPAM -- so that's
actually a bug by the looks of it.

Even on servers where it is the case that /tmp grows over time, it
strikes me that tmpfs gives the system a much better chance to make
sensible decisions about when to write data out to disk.

On a mounted file system the system will attempt to ensure that the data
gets out to disk in a reasonably timely manner, since it's trying to
ensure that it's not lost in the event of a crash -- in that case of
/tmp, any effort to keep the normal file-system promise of post-crash
integrity is wasted effort, since we're going to throw the data away
anyway.

With tmpfs on the other hand, the data will never hit the disk if there
is enough RAM, and if there is a need to write it out, it'll generally
write the oldest data out first, so the portions of the tmpfs that are
being used for short-lived files will generally not be written before
those files are deleted again, so that they never need to be written at
all.

> so without low enough limits one risks that something
> important is sometime not working because of missing RAM).

If you'd read what I wrote, I suggested that a reasonable start would be
to allocate the /tmp filesystem space as swap, and then limit /tmp to
that size -- even if you then fill /tmp it cannot exceed the extra size
that you allocated to swap by giving it the disk that you'd otherwise be
using for /tmp as a file system.

Admittedly, I think that using the amount the we currently allocate to
/tmp for swap would be a waste, but it's a reasonable starting point.

In fact, it wouldn't surprise me if the act of mounting an additional
filesystem consumes more memory than a tmpfs with 8kb of files on it, so
for the first server mentioned above I may well be consuming less RAM
than I would be mounting an empty /tmp from the disk.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
 
Old 04-13-2011, 02:44 PM
David Goodenough
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wednesday 13 April 2011, Ben Hutchings wrote:
> On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
> > * Philip Hands <phil@hands.com> [110413 12:54]:
> > > This strikes me as suboptimal, since one could use the disk space
> > > allocated to /tmp as extra swap and then allocate a tmpfs of that size
> > > to be mounted on /tmp with no effect other than allowing the system to
> > > have access to more swap than it would have otherwise had (of course,
> > > that's probably more than it needs, so instead you could just save some
> > > disk space that would otherwise be left generally unused by overloading
> > > the swap usage with /tmp usage.
> > >
> > > Therefore, in the multi-partition setup, I think we should also default
> > > to having /tmp on tmpfs.
> >
> > This has both the disadvantage of a system then having swap (given the
> > big memory sizes one currently has and the big difference between RAM
> > and disk access times, having swap is often quite a disadvantage)
>
> [...]
>
> Under Linux, swap space is a requirement to defragment RAM. (This may
> change in the future.) Without swap space, the kernel eventually
> becomes unable to make large physically-contiguous allocations. Don't
> turn it off.
>
> Ben.
I am surprised at this. I have several boxes which are small single board
computers with solid state disks (MIDE or CF), so as I did not need swap
space (the running set is fixed and the memory requirement was within
the total available memory, I did not define any swap space. A few days
ago I needed to move one of the boxes I noted its uptime at 594 days just
before I switched it off. I grant you that it has 256MB of memory, and
120MB is currently free, but I have not noticed any problems growing over
the time it was up. Maybe it just did not need to make any large physically
contiguous allocations.

BTW, /var/run is currently occupying a grand total of 27KB if that is relevant
to the subject of this thread.

David


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201104131544.37402.david.goodenough@btconnect.com" >http://lists.debian.org/201104131544.37402.david.goodenough@btconnect.com
 
Old 04-13-2011, 03:17 PM
Philipp Kern
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On 2011-04-13, David Goodenough <david.goodenough@btconnect.com> wrote:
> I am surprised at this. I have several boxes which are small single board
> computers with solid state disks (MIDE or CF), so as I did not need swap
> space (the running set is fixed and the memory requirement was within
> the total available memory, I did not define any swap space. A few days
> ago I needed to move one of the boxes I noted its uptime at 594 days just
> before I switched it off. I grant you that it has 256MB of memory, and
> 120MB is currently free, but I have not noticed any problems growing over
> the time it was up. Maybe it just did not need to make any large physically
> contiguous allocations.

Given that Linux does paging, you normally don't need large physically
contiguous allocations. I think the exceptions are mainly I/O regions for
DMA. And you're probably not using that heavily on such a machine.

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniqbfk4.rnn.trash@kelgar.0x539.de">http://lists.debian.org/slrniqbfk4.rnn.trash@kelgar.0x539.de
 

Thread Tools




All times are GMT. The time now is 05:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org