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

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