[Q] don't allow tmpfs to page out

[Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Is it possible to disable the tmpfs feature to page out
memory to swap?
I didn't find any mount option or something like that
for it in the documentation.

- --
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9UklFGK1OIvVOP4RAvlyAKC0Aoug0HRSa8zRQuFAH8ufFY1C+wCg0ycG
uMXEYVntwUiiueZloUnizPo=
=t1IM
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[William Stearns]

Good afternoon, Michael,

On Wed, 14 Jul 2004, Michael Buesch wrote:

> Is it possible to disable the tmpfs feature to page out
> memory to swap?
> I didn't find any mount option or something like that
> for it in the documentation.

	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
you want.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Heisenberg _may_ have slept here."
(Courtesy of Rick Stevens <rstevens@vitalstream.com>)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at:   http://www.stearns.org
--------------------------------------------------------------------------

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting William Stearns <wstearns@pobox.com>:
> Good afternoon, Michael,

Hi William,

> 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> you want.

No, since a regular ramdisk is static in size.

> 	Cheers,
> 	- Bill

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VZvFGK1OIvVOP4RAku8AJ92P7fjMBBAkf36vKTlYQvH1XluzQCfQ573
LQyLzVpA5o5UfAH/3G2Aq3s=
=jzzh
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

On Wed, 2004-07-14 at 17:51, Michael Buesch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Quoting William Stearns <wstearns@pobox.com>:
> > Good afternoon, Michael,
> 
> Hi William,
> 
> > 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> > you want.
> 
> No, since a regular ramdisk is static in size.

which is why there is ramfs .. :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Arjan van de Ven <arjanv@redhat.com>:
> On Wed, 2004-07-14 at 17:51, Michael Buesch wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Quoting William Stearns <wstearns@pobox.com>:
> > > Good afternoon, Michael,
> > 
> > Hi William,
> > 
> > > 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> > > you want.
> > 
> > No, since a regular ramdisk is static in size.
> 
> which is why there is ramfs .. :)

In 2.4, too? Can't find it.
What's the CONFIG_* of ramfs?

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VlGFGK1OIvVOP4RAn3HAJ9fU0KX6FNJDQwn9gVFGKA506eivgCfd28S
zBmNkGBYQd4lmSmUVSzvmGA=
=eejH
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > 
> > which is why there is ramfs .. :)
> 
> In 2.4, too? Can't find it.
> What's the CONFIG_* of ramfs?

CONFIG_RAMFS


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

Quoting Arjan van de Ven <arjanv@redhat.com>:
> On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > >
> > > which is why there is ramfs .. :)
> >
> > In 2.4, too? Can't find it.
> > What's the CONFIG_* of ramfs?
>
> CONFIG_RAMFS

Ok, that's the thing /dev/ram* is about, isn't it?
I already have a /dev/ram mounted somewhere, but it's
not dynamic in size. What am I missing. I'm kind of
confused now. :)

--
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Wed, Jul 14, 2004 at 06:07:08PM +0200, Michael Buesch wrote:
> Quoting Arjan van de Ven <arjanv@redhat.com>:
> > On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > > >
> > > > which is why there is ramfs .. :)
> > >
> > > In 2.4, too? Can't find it.
> > > What's the CONFIG_* of ramfs?
> >
> > CONFIG_RAMFS
> 
> Ok, that's the thing /dev/ram* is about, isn't it?

nope

> I already have a /dev/ram mounted somewhere, but it's
> not dynamic in size. What am I missing. I'm kind of
> confused now. :)

yes you are;

just do 
mount -t ramfs none /mnt/point


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Arjan van de Ven <arjanv@redhat.com>:
> yes you are;
> 
> just do 
> mount -t ramfs none /mnt/point

Oho, didn't know that. thanks. 8-}

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VtOFGK1OIvVOP4RAkUVAJ9r+jZNnOrqvgQbUJM0hfPg310aiwCfaayJ
E9kxdYqT+06O4Vbn1xF19SA=
=yABs
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[christophe.varoqui]

> 
> just do 
> mount -t ramfs none /mnt/point
> 
Would that be a suitable solution to store callout binaries for daemons like
multipathd that need to work in case of system-disk outage (/bin & swap on SAN
for example) ?

If so, is it possible and/or correct for the daemon to do a private ramfs mount
for this purpose ?

And while I'm at throwing all the questions I have on my mind :
* how can I disable on-demand loading for the daemon ?
* does mlockall() provides all the necessary garanties ?
* what explains the "offset-by-4" between VSZ and RSS I see when running
mlockall'ed daemon ?

Thanks for the educational work :)

regards,
cvaroqui

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]


On Thu, Jul 15, 2004 at 09:58:37AM +0200, christophe.varoqui@free.fr wrote:
> > 
> > just do 
> > mount -t ramfs none /mnt/point
> > 
> Would that be a suitable solution to store callout binaries for daemons like
> multipathd that need to work in case of system-disk outage (/bin & swap on SAN
> for example) ?

somewhat, as long as ALL requirements are there, including all libraries ;)

> If so, is it possible and/or correct for the daemon to do a private ramfs mount
> for this purpose ?

sure; namespaces can do a LOT
> 
> And while I'm at throwing all the questions I have on my mind :
> * how can I disable on-demand loading for the daemon ?
> * does mlockall() provides all the necessary garanties ?

mlockall does not guarantee that syscalls you do don't cause memory
allocations, nor does the ramfs approach.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[christophe.varoqui]

Selon Arjan van de Ven <arjanv@redhat.com>:

> 
> On Thu, Jul 15, 2004 at 09:58:37AM +0200, christophe.varoqui@free.fr wrote:
> > > 
> > > just do 
> > > mount -t ramfs none /mnt/point
> > > 
> > Would that be a suitable solution to store callout binaries for daemons
> like
> > multipathd that need to work in case of system-disk outage (/bin & swap on
> SAN
> > for example) ?
> 
> somewhat, as long as ALL requirements are there, including all libraries ;)
> 
ok, sure.
klibc linked static binaries in my case (scsi_id & multipath), so it should be ok.

> > If so, is it possible and/or correct for the daemon to do a private ramfs
> mount
> > for this purpose ?
> 
> sure; namespaces can do a LOT

Somehow "man 2 mount" is not so verbose about that "lot" :)
Can you feed a pointer to a doc explaining how to achieve such privacy ?

> > 
> > And while I'm at throwing all the questions I have on my mind :
> > * how can I disable on-demand loading for the daemon ?
> > * does mlockall() provides all the necessary garanties ?
> 
> mlockall does not guarantee that syscalls you do don't cause memory
> allocations, nor does the ramfs approach.
> 
mmm ... more questions than I had before :)
any hint about how to solve this issue ?

regards,
cvaroqui


-- 

namespaces (was Re: [Q] don't allow tmpfs to page out)

[Paul Jakma]

On Thu, 15 Jul 2004, Arjan van de Ven wrote:

> sure; namespaces can do a LOT

speaking of which, how does one use namespaces exactly? The kernel 
appears to maintain mount information per process, but how do you set 
this up?

neither 'man mount/namespace' nor 'appropos namespace' show up 
anything.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
 	A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and Chaucer."

Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Thu, Jul 15, 2004 at 01:31:08PM +0100, Paul Jakma wrote:
> On Thu, 15 Jul 2004, Arjan van de Ven wrote:
> 
> >sure; namespaces can do a LOT
> 
> speaking of which, how does one use namespaces exactly? The kernel 
> appears to maintain mount information per process, but how do you set 
> this up?
> 
> neither 'man mount/namespace' nor 'appropos namespace' show up 
> anything.

it's a clone() flag....

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[Paul Jakma]

On Thu, 15 Jul 2004, Arjan van de Ven wrote:

> it's a clone() flag....

Ah, very cute.

Are there any tools yet to make use of it?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam@dishone.st
Fortune:
Boucher's Observation:
 	He who blows his own horn always plays the music
 	several octaves higher than originally written.

Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[Andries Brouwer]

On Thu, Jul 15, 2004 at 01:31:08PM +0100, Paul Jakma wrote:

> speaking of which, how does one use namespaces exactly? The kernel 
> appears to maintain mount information per process, but how do you set 
> this up?
> 
> neither 'man mount/namespace' nor 'appropos namespace' show up 
> anything.

Try "man 2 clone" and look for CLONE_NEWNS.

Somewhere else I wrote

  Since 2.4.19/2.5.2, the clone() system call, a generalization of
  Unix fork() and BSD vfork(), may have the CLONE_NEWNS flag, that
  says that all mount information must be copied. Afterwards, mount,
  chroot, pivotroot and similar namespace changing calls done by this
  new process do influence this process and its children, but not other
  processes. In particular, the virtual file /proc/mounts that lists the
  mounted filesystems, is now a symlink to /proc/self/mounts - different
  processes may live in entirely different file hierarchies.

Andries

Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[Rutger Nijlunsing]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Thu, Jul 15, 2004 at 07:19:09PM +0200, Andries Brouwer wrote:
> On Thu, Jul 15, 2004 at 01:31:08PM +0100, Paul Jakma wrote:
> 
> > speaking of which, how does one use namespaces exactly? The kernel 
> > appears to maintain mount information per process, but how do you set 
> > this up?
> > 
> > neither 'man mount/namespace' nor 'appropos namespace' show up 
> > anything.
> 
> Try "man 2 clone" and look for CLONE_NEWNS.
> 
> Somewhere else I wrote
> 
>   Since 2.4.19/2.5.2, the clone() system call, a generalization of
>   Unix fork() and BSD vfork(), may have the CLONE_NEWNS flag, that
>   says that all mount information must be copied. Afterwards, mount,
>   chroot, pivotroot and similar namespace changing calls done by this
>   new process do influence this process and its children, but not other
>   processes. In particular, the virtual file /proc/mounts that lists the
>   mounted filesystems, is now a symlink to /proc/self/mounts - different
>   processes may live in entirely different file hierarchies.
> 
> Andries

Or your page at

  http://www.win.tue.nl/~aeb/linux/lk/lk-6.html

...which contains a working utility (section 6.3.3).

Attached an adopted version. Call like 'newnamespace /bin/bash' to
start bash in a new namespace.

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

[-- Attachment #2: newnamespace.c --]
[-- Type: text/plain, Size: 1166 bytes --]

/* newnamespace.c */

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <sched.h>
#include <sys/types.h>
#include <sys/wait.h>

typedef struct {
  char *path;
  char **argv;
} FuncInfo;

int childfn(void *p) {
  FuncInfo *fi = (FuncInfo *)p;

  /*  setenv("PS1", "@@ ", 1); */
  execv(fi->path, fi->argv);
  perror("execl");
  fprintf(stderr, "Cannot exec '%s'\n", fi->path);
  exit(1);
}

static char *default_path = "/bin/ash";
static char *default_argv[] = {"ash", NULL};

int main(int argc, char *argv[]) {
  char buf[10000];
  pid_t pid, p;
  
  FuncInfo fi;

  if (argc == 1) {
    /* No arguments given */
    fi.path = default_path;
    fi.argv = default_argv;
  } else {
    int i;
    argc--; argv++;
    fi.path = *argv;
    fi.argv = (char **)malloc(sizeof(char *) * (argc + 1));
    for (i = 0; i < argc; i++) {
      fi.argv[i] = argv[i];
    }
    fi.argv[argc] = NULL;
  }

  pid = clone(childfn, buf + 5000, CLONE_NEWNS | SIGCHLD, &fi);
  if ((int) pid == -1) {
    perror("clone");
    exit(1);
  }
  
  p = waitpid(pid, NULL, 0);
  if ((int) p == -1) {
    perror("waitpid");
    exit(1);
  }
  
  exit(0);
}

Re: [dm-devel] Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[christophe varoqui]

On jeu, 2004-07-15 at 14:31, Arjan van de Ven wrote:
> On Thu, Jul 15, 2004 at 01:31:08PM +0100, Paul Jakma wrote:
> > On Thu, 15 Jul 2004, Arjan van de Ven wrote:
> > 
> > >sure; namespaces can do a LOT
> > 
> > speaking of which, how does one use namespaces exactly? The kernel 
> > appears to maintain mount information per process, but how do you set 
> > this up?
> > 
> > neither 'man mount/namespace' nor 'appropos namespace' show up 
> > anything.
> 
> it's a clone() flag....

will execv() inherits the caller's namespace ?

regards,
cvaroqui

Re: [dm-devel] Re: namespaces (was Re: [Q] don't allow tmpfs to page out)

[Chris Wedgwood]

On Fri, Jul 16, 2004 at 12:35:46AM +0200, christophe varoqui wrote:

> will execv() inherits the caller's namespace ?

yes