archive mirror
 help / color / mirror / Atom feed
From: Sargun Dhillon <>
	Alexander Viro <>,
	Amir Goldstein <>
Cc: Sargun Dhillon <>,
	Giuseppe Scrivano <>,
	Vivek Goyal <>,
	Daniel J Walsh <>,,
	David Howells <>
Subject: [PATCH v1 0/3] Make overlayfs volatile mounts reusable
Date: Wed, 25 Nov 2020 02:46:18 -0800	[thread overview]
Message-ID: <> (raw)

The volatile option is great for "ephemeral" containers. Unfortunately,
it doesn't capture all uses. There are two ways to use it safely right now:

1. Throw away the entire upperdir between mounts
2. Manually syncfs between mounts

For certain use-cases like serverless, or short-lived containers, it is
advantageous to be able to stop the container (runtime) and start it up on
demand / invocation of the function. Usually, there is some bootstrap
process which involves downloading some artifacts, or putting secrets on
disk, and then upon invocation of the function, you want to (re)start the

If you have to syncfs every time you do this, it can lead to excess
filesystem overhead for all of the other containers on the machine, and
stall out every container who's upperdir is on the same underlying
filesystem, unless your filesystem offers something like subvolumes,
and if sync can be restricted to a subvolume.

The kernel has information that it can use to determine whether or not this
is safe -- primarily if the underlying FS has had writeback errors or not.
Overlayfs doesn't delay writes, so the consistency of the upperdir is not
contingent on the mount of overlayfs, but rather the mount of the
underlying filesystem. It can also make sure the underlying filesystem
wasn't remounted. Although, it was suggested that we use derive this
information from the upperdir's inode[1], we can checkpoint this data on
disk in an xattr.

Specifically we checkpoint:
  * Superblock "id": This is a new concept introduced in one of the patches
    which keeps track of (re)mounts of filesystems, by having a per boot
    monotonically increasing integer identifying the superblock. This is
    safer than trying to obfuscate the pointer and putting it into an
    xattr (due to leak risk, and address reuse), and during the course
    of a boot, the u64 should not wrap.
  * Overlay "boot id": This is a new UUID that is overlayfs specific,
    as overlayfs is a module that's independent from the rest of the
    system and can be (re)loaded independently -- thus it generates
    a UUID at load time which can be used to uniquely identify it.
  * upperdir / workdir errseq: A sample of the errseq_t on the workdir /
    upperdir's superblock. Since the errseq_t is implemented as a u32
    with errno + error counter, we can safely store it in a checkpoint.

This has to be done in kernelspace because userspace does not have access
to information such as superblock (re)mounts, the writeback errseq value,
and whether the module has been (re)loaded. Although this mechanism only
determines a subset of the error scenarios, it lays out the groundwork
for adding more.

In the future, we may want to make it so overlayfs shuts down on errors,
or have some kind of other behaviour when errors are detected. If we want
a per-file (on the upperdir) piece of metadata can be added indicating
errseq_t for just that file, and we can check it on each close / open,
and then allow the user to make an intelligent decision of how they want
overlayfs to handle the error. This would allow for errors to be captured
during normal operation as opposed to just between remounts.

RFC [2]:
 * Changed datastructure names
 * No longer delete the volatile dir / dirty file
 * Moved xattr to volatile directory
 * Split errseq check


Sargun Dhillon (3):
  fs: Add s_instance_id field to superblock for unique identification
  overlay: Add the ability to remount volatile directories when safe
  overlay: Add rudimentary checking of writeback errseq on volatile

 Documentation/filesystems/overlayfs.rst |  6 +-
 fs/overlayfs/overlayfs.h                | 38 +++++++++-
 fs/overlayfs/readdir.c                  | 94 +++++++++++++++++++++----
 fs/overlayfs/super.c                    | 75 +++++++++++++++-----
 fs/overlayfs/util.c                     |  2 +
 fs/super.c                              |  3 +
 include/linux/fs.h                      |  7 ++
 7 files changed, 193 insertions(+), 32 deletions(-)


             reply	other threads:[~2020-11-25 10:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 10:46 Sargun Dhillon [this message]
2020-11-25 10:46 ` [PATCH v1 1/3] fs: Add s_instance_id field to superblock for unique identification Sargun Dhillon
2020-11-25 10:46 ` [PATCH v1 2/3] overlay: Add the ability to remount volatile directories when safe Sargun Dhillon
2020-11-25 12:49   ` kernel test robot
2020-11-25 13:23   ` kernel test robot
2020-11-25 13:29   ` kernel test robot
2020-11-25 13:58   ` Amir Goldstein
2020-11-25 14:43   ` Vivek Goyal
2020-11-25 15:29     ` Sargun Dhillon
2020-11-25 18:17   ` Vivek Goyal
2020-11-25 18:31     ` Sargun Dhillon
2020-11-25 18:43       ` Vivek Goyal
2020-11-25 18:47         ` Sargun Dhillon
2020-11-25 18:52           ` Vivek Goyal
2020-11-25 19:37             ` Amir Goldstein
2020-11-25 10:46 ` [PATCH v1 3/3] overlay: Add rudimentary checking of writeback errseq on volatile remount Sargun Dhillon
2020-11-25 14:03   ` Amir Goldstein
2020-11-25 15:36     ` Vivek Goyal
2020-11-25 15:52       ` Amir Goldstein

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).