linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Josh England <jjengla@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: overlayfs: allowing for changes to lowerdir
Date: Wed, 15 Feb 2017 10:29:49 +0900	[thread overview]
Message-ID: <8172.1487122189@jrobl> (raw)
In-Reply-To: <CA+ZH+jFBAaRi6VPmf3PBdDZQQMOaT6WUByATqaw1QL5M9+-dxg@mail.gmail.com>

Josh England:
> So, let me pose this somewhat naive question:  Would it be possible to
> simply disable any cacheing performed by the overlay to force all
> reads to go to either the tmpfs upper or the (VFS-cached) NFS lower?
> Would this be enough to accomplish my goal of being able to change the
> lowerdir of an active overlayfs?

For your information, aufs allows by-passing aufs, ie. the modification
on the layers or UDBA (user's direct branch access). Internally aufs
sets the inotify to the cached dir inodes and recieves the notification
when the files on the branches (layers) are modified. Recieving the
notification, aufs marks the cached inode obsolete. Next time when the
access happens, aufs_d_revalidate() checks the mark and forces VFS to to
re-lookup.
You can enable/disable this feature anytime by
"mount -o remount,udba=brabra ..."


J. R. Okajima

      parent reply	other threads:[~2017-02-15  1:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 21:41 overlayfs: allowing for changes to lowerdir Josh England
2017-02-14 14:01 ` Amir Goldstein
2017-02-14 17:14   ` Josh England
2017-02-21 23:08   ` Josh England
2017-02-22  9:00     ` Ian Kent
2017-02-27 10:40     ` Amir Goldstein
2017-02-28 19:08       ` Josh England
2017-02-28 19:44         ` Al Viro
2017-03-01 11:15           ` Amir Goldstein
2017-03-01 18:22           ` Josh England
2017-03-01 20:22         ` Colin Walters
2017-03-09 10:37   ` Miklos Szeredi
2017-03-09 11:22     ` Amir Goldstein
2017-03-09 13:12       ` Miklos Szeredi
2017-02-15  1:29 ` J. R. Okajima [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=8172.1487122189@jrobl \
    --to=hooanon05g@gmail.com \
    --cc=jjengla@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).