Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit :
Therefore, in the multi-partition setup, I think we should also default
to having /tmp on tmpfs.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245465
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way
Roger Leigh rle...@codelibre.net writes:
On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
If it wasn't already clear, having /tmp as a tmpfs is a
/configurable option/, and it is /not/ the default (except when
root is
On Sat, Apr 16, 2011 at 09:35:53AM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
If it wasn't already clear, having /tmp as a tmpfs is a
On Sat, 16 Apr 2011 09:17:04 +0200, Josselin Mouette j...@debian.org wrote:
Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit :
Therefore, in the multi-partition setup, I think we should also default
to having /tmp on tmpfs.
On Sat, Apr 16, 2011 at 11:31:08AM +0100, Philip Hands wrote:
On Sat, 16 Apr 2011 09:17:04 +0200, Josselin Mouette j...@debian.org wrote:
Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit :
Therefore, in the multi-partition setup, I think we should also default
to having /tmp
Roger Leigh rle...@codelibre.net writes:
On Sat, Apr 16, 2011 at 09:35:53AM +0200, Goswin von Brederlow wrote:
To me that reads like you will mount a tmpfs on /tmp if root is
read-only even if RAMTMP is not set. Which is wrong if the system has a
/tmp filesystem in /etc/fstab.
This is a
On Thu, Apr 14, 2011 at 09:27:23AM -0400, Marvin Renich wrote:
* Luca Capello l...@pca.it [110414 06:43]:
Hi there!
Disclaimer: this is my last post on this matter (i.e. the meaning of
RAMLOCK), it seems there is a problem with myself or my understanding.
Either I do not read `man
New text, which is hopefully clear enough:
RAMLOCK
Make /run/lock/ available as a ram file system (tmpfs). Set to
'yes' to enable, to 'no' to disable (defaults to yes). The size
of the tmpfs can be controlled using TMPFS_SIZE and LOCK_SIZE in
/etc/default/tmpfs. Note that
On Fri, Apr 15, 2011 at 12:58:19PM +0200, Bastien ROUCARIES wrote:
New text, which is hopefully clear enough:
RAMLOCK
Make /run/lock/ available as a ram file system (tmpfs). Set to
'yes' to enable, to 'no' to disable (defaults to yes). The size
of the tmpfs can be controlled
Bastien ROUCARIES roucaries.bast...@gmail.com writes:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
Following the discussion
Roger Leigh rle...@codelibre.net writes:
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On Tue, Apr 12, 2011 at 12:38:03PM
John D. Hendrickson and Sara Darnell johnandsa...@cox.net writes:
I'm reading (can't spend allot of time though, I'll try)
initscripts_2.88dsf-13.3_amd64.deb
sysvinit_2.88dsf-13.3.dsc
I'm thinking (I'm not sure) that Bastien is working on this. He'd
mentioned issues between
On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
If it wasn't already clear, having /tmp as a tmpfs is a
/configurable option/, and it is /not/ the default (except when
root is read-only (ro) in fstab).
I hope you check the
On Fri, 15 Apr 2011, Roger Leigh wrote:
For new installs, where the default /etc/default/rcS files does
set RAMTMP=yes by default, the fstab file will not yet contain
any user-specific mounts. If they do want to manuall mount
something on /tmp, then they simply set RAMTMP=no.
Hopefully you
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
Following the discussion yesterday, I'd like to propose doing
something like the
On to, 2011-04-14 at 10:44 +0200, Bastien ROUCARIES wrote:
And moreover for scientific computation /tmp need to be on an
harddisk. I do not want my 16GiB matric to go to memory when I have
only 8GiB of RAM
That sounds like you'd be better off using /var/tmp instead, actually.
Please do
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
Following the
On Thu, Apr 14, 2011 at 11:50:52AM +0930, Karl Goetz wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
Proposal:
[...]
/tmp: No default (use general tmpfs default of 20%)
20% doesn't seem like a lot for /tmp when people try and compile
something. While
On Thu, Apr 14, 2011 at 11:15 AM, Roger Leigh rle...@codelibre.net wrote:
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On
On Thu, Apr 14, 2011 at 11:32 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Thu, Apr 14, 2011 at 11:15 AM, Roger Leigh rle...@codelibre.net wrote:
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au
Hi there!
Disclaimer: this is my last post on this matter (i.e. the meaning of
RAMLOCK), it seems there is a problem with myself or my understanding.
On Tue, 12 Apr 2011 23:42:58 +0200, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote:
On Tue, 12 Apr 2011
Hi there!
Just to be sure everyone gets it correctly...
On Thu, 14 Apr 2011 11:15:07 +0200, Roger Leigh wrote:
If it wasn't already clear, having /tmp as a tmpfs is a
/configurable option/, and it is /not/ the default (except when
root is read-only (ro) in fstab).
Sorry, having /tmp as a
fuser(1)
In the postinst (or other) it seems you wish to know if your impacting
things, are not all sure about the vserver situation, and are using
stat(1) and test -L and etc.
You might try fuser(1) so you are sure if /var/run will impact something.
Luca Capello wrote:
Hi there!
I'm reading (can't spend allot of time though, I'll try)
initscripts_2.88dsf-13.3_amd64.deb
sysvinit_2.88dsf-13.3.dsc
I'm thinking (I'm not sure) that Bastien is working on this. He'd
mentioned issues between sysinit and running on certain vservers.
While reading scripts it
I've noticed I have to check /etc carefully.
Some rc.d scripts that packages install edit and or activate things in
/etc (they make insertions into automatically actived scripts in /etc
for ssh, ppp, perl, network (pre-ifupdown or what), exim, things or
other possible phone home things).
* Luca Capello l...@pca.it [110414 06:43]:
Hi there!
Disclaimer: this is my last post on this matter (i.e. the meaning of
RAMLOCK), it seems there is a problem with myself or my understanding.
Either I do not read `man rcS` as you read it or we do not understand
each other, so here the
On Thu, 14 Apr 2011 10:15:07 +0100, Roger Leigh rle...@codelibre.net wrote:
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
One last rc.d comment. (noting I use a variety but try to stick with
latest)
For 20 yrs. every time I try NFS during boot scripts, no matter which
linux, I tend to get my linux frozen when nfs can't mount.
I have yet to see an NFS that offers file access in a suitable manner
(ie, error
On Thu, Apr 14, 2011 at 02:13:57PM +0100, Philip Hands wrote:
On Thu, 14 Apr 2011 10:15:07 +0100, Roger Leigh rle...@codelibre.net wrote:
On Thu, Apr 14, 2011 at 10:44:08AM +0200, Bastien ROUCARIES wrote:
On Thu, Apr 14, 2011 at 4:20 AM, Karl Goetz k...@kgoetz.id.au wrote:
On Wed, 13 Apr
Roger Leigh rle...@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
On Wed, Apr 13, 2011 at 10:29:16AM +0200, Stig Sandbeck Mathisen wrote:
Roger Leigh rle...@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,
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
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*
On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@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
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
On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@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
* Philip Hands p...@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
On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
* Philip Hands p...@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
On Wed, 13 Apr 2011 13:34:13 +0200, Bernhard R. Link brl...@debian.org
wrote:
* Philip Hands p...@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
On Wednesday 13 April 2011, Ben Hutchings wrote:
On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
* Philip Hands p...@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
On 2011-04-13, David Goodenough david.goodeno...@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
* Philip Hands p...@hands.com [110413 15:51]:
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 you don't use it it will hopefully make not much big difference.
The difference is if it gets used. If some program goes
I just realized that I misunderstood Roger Leigh's posting and so
my previous message was mostly superfluous. My apologies.
1. His statement but you have to mount many more to be able to
break your system was correct (and can be made more explicit by
adding ... by filling them all).
2. His
On Wed, Apr 13, 2011 at 03:17:24PM +, Philipp Kern wrote:
On 2011-04-13, David Goodenough david.goodeno...@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
On Wednesday 13 April 2011, Ben Hutchings wrote:
On Wed, Apr 13, 2011 at 03:17:24PM +, Philipp Kern wrote:
On 2011-04-13, David Goodenough david.goodeno...@btconnect.com wrote:
I am surprised at this. I have several boxes which are small single
board computers with solid state disks
On Wed, Apr 13, 2011 at 05:21:18PM +0200, Thomas Hood wrote:
I just realized that I misunderstood Roger Leigh's posting and so
my previous message was mostly superfluous. My apologies.
1. His statement but you have to mount many more to be able to
break your system was correct (and can be
On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh rle...@codelibre.net wrote:
On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
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
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
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
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
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
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
Hi there!
On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
Josh Triplett suggested that we could use a single tmpfs on /run and
have the rest as symlinks into /run, with potentially a separate
tmpfs for user-writable filesystems to prevent a user DoS. This idea
does have merit, and we
On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
Hi there!
On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
Josh Triplett suggested that we could use a single tmpfs on /run and
have the rest as symlinks into /run, with potentially a separate
tmpfs for user-writable
On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
With the patch as it stands at present, RAMRUN is deprecated. /run
is always a tmpfs; RUN_SIZE will set its size, as before.
Hmm, just thinking... vServers don't really allow mounting AFAIK as that
would be the host's job. Wouldn't
On Tue, Apr 12, 2011 at 07:44:54AM -0700, Steve Langasek wrote:
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
On Tue, Apr 12, 2011 at 09:07:48PM +0200, Jan Hauke Rahm wrote:
On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
With the patch as it stands at present, RAMRUN is deprecated. /run
is always a tmpfs; RUN_SIZE will set its size, as before.
Hmm, just thinking... vServers don't
On Tue, Apr 12, 2011 at 08:21:25PM +0100, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 09:07:48PM +0200, Jan Hauke Rahm wrote:
On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
With the patch as it stands at present, RAMRUN is deprecated. /run
is always a tmpfs; RUN_SIZE will
On Tue, Apr 12, 2011 at 08:19:59PM +0100, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 07:44:54AM -0700, Steve Langasek wrote:
If the problem is that multiple tmpfs are mounted and
each can expand to half-of-RAM, either reduce the number of tmpfses
presented (as discussed), or limit the
]] Roger Leigh
| I think that if we have /run/lock, /run/shm makes sense (how different
| are locks and POSIX semaphores? They are just a different type of
| lock (broadly). And shared memory is ephemeral state, just like
| samba's state etc.). So I would argue that it does fit. But this
|
On 2011-04-12, Roger Leigh rle...@codelibre.net wrote:
Having multiple tmpfses with the kernel defaults means that a user or
badly written program could intentionally or accidentally lock up the
machine by using all available memory by filling up one or more of the
tmpfses. And the majority
Hi there!
On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
Josh Triplett suggested that we could use a single tmpfs on /run and
have the rest as symlinks into /run,
On Tue, Apr 12, 2011 at 10:08:30PM +0200, Tollef Fog Heen wrote:
]] Roger Leigh
| I think that if we have /run/lock, /run/shm makes sense (how different
| are locks and POSIX semaphores? They are just a different type of
| lock (broadly). And shared memory is ephemeral state, just like
|
On Tue, Apr 12, 2011 at 08:22:00PM +, Philipp Kern wrote:
On 2011-04-12, Roger Leigh rle...@codelibre.net wrote:
Having multiple tmpfses with the kernel defaults means that a user or
badly written program could intentionally or accidentally lock up the
machine by using all available
On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote:
Hi there!
On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote:
On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
Josh Triplett suggested that we could use a
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
66 matches
Mail list logo
