All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Jones <ejones@cray.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-unionfs@vger.kernel.org
Subject: Re: overlayfs lazy unmounts?
Date: Tue, 27 Jan 2015 12:41:36 -0800	[thread overview]
Message-ID: <20150127204136.GY32617@cray.com> (raw)
In-Reply-To: <CAJfpegtAL7dGhhRW3x8kEygXAQrW-_mdzEt3NiOo6ETaXkYOCg@mail.gmail.com>

CC'ing linux-unionfs

On Mon, Jan 26, 2015 at 06:00:35PM +0100, Miklos Szeredi wrote:
> On Fri, Jan 23, 2015 at 7:03 PM, Eric Jones <ejones <at> cray.com> wrote:
> > Hi. Thanks for overlayfs.
> >
> > We're using overlayfs, and we're trying to deal with the "undefined" behavior when modifying the lower layer. The approach we are taking is to lazy unmount all overlays, modify the lower layer, and remount with the same upper/lower.
> >
> > Would you expect processes with references to the lazily unmounted overlayfs to behave? Even if the overlay is immediately recreated?
> 
> While referencing the old overlay they will behave in an undefined
> way, regardless of the recreated overlay.
> 
> Now "undefined" does not necessarily mean it will do something bad.
> Depends on what you expect it to do...
> 
> What's the use case?  Why and how are you modifying the lower layer?

Consider managing /opt on a very large diskless cluster. Lower layer is NFS. Upper layer is tmpfs. Upper has portions of /opt we want in memory for performance considerations.

Lower could be one of:
server:/var/images/opt_A
server:/var/images/opt_B
server:/var/images/opt_C
server:/var/images/opt_XXXX

Upper is tmpfs /.opt and they are overlayfs mounted on /opt.

So this would be a typical mount command:
 mount -t overlayfs -olowerdir=/var/images/opt_A,upperdir=/.opt none /opt

1. Will creating new verions of /var/images/opt_XXXX on the NFS server affect existing overlayfs mounts? The docs say modifying the lower filesystem is not allowed, but will anything "bad" happen if we are just adding a sibling directory tree that is not yet overlay mounted? 

2. We switch to a new /var/images/opt_XXXX by doing a lazy unmount of the old and mounting the new. Will processes with outstanding references see broken pwd/cwd? Corruption? 

> 
> Thanks,
> Miklos
> 
> PS. Would you mind including the unionfs mailing list
> <linux-unionfs@vger.kernel.org> in the discussion?

       reply	other threads:[~2015-01-27 20:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150123180309.GN32617@cray.com>
     [not found] ` <CAJfpegtAL7dGhhRW3x8kEygXAQrW-_mdzEt3NiOo6ETaXkYOCg@mail.gmail.com>
2015-01-27 20:41   ` Eric Jones [this message]
2015-01-28  1:23     ` overlayfs lazy unmounts? Ian Kent
2015-01-28  3:59     ` hujianyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150127204136.GY32617@cray.com \
    --to=ejones@cray.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.