From: hujianyang <hujianyang@huawei.com>
To: Eric Jones <ejones@cray.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org, raven@themaw.net
Subject: Re: overlayfs lazy unmounts?
Date: Wed, 28 Jan 2015 11:59:49 +0800 [thread overview]
Message-ID: <54C85EB5.8040306@huawei.com> (raw)
In-Reply-To: <20150127204136.GY32617@cray.com>
On 2015/1/28 4:41, Eric Jones wrote:
>
> 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?
Overlayfs doesn't affect lowerfs but may cache some filesystem
data of lowerfs in memory. I think if the sibling directory is
entirely independent with the lowerdir of overlayfs, modifying
is OK.
But there are many using case in filesystem, e.g. link, may affect
the lowerdir even if the operations is performed on sibling dir.
Keep lowerfs stable is safe.
>
> 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?
New mount will create new metadata in my considering. They are
different mount for OS. You are worry about that new mount and
old mount may modify upperdir in the same time, Am I right? So
I think it is similar with the case that mounting two different
overlayfs with same upperdir, I think you could handle it in
userspace.
What's your use case? You can try something first and see what
will happen, then send out the result.
BR,
Hu
prev parent reply other threads:[~2015-01-28 4:03 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 ` overlayfs lazy unmounts? Eric Jones
2015-01-28 1:23 ` Ian Kent
2015-01-28 3:59 ` hujianyang [this message]
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=54C85EB5.8040306@huawei.com \
--to=hujianyang@huawei.com \
--cc=ejones@cray.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
/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.