All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>,
	Neil Brown <neilb@suse.de>,
	linux-unionfs@vger.kernel.org,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: How to cope with two incompatible overlayfs formats out in the wild
Date: Tue, 18 Nov 2014 17:07:18 +0000	[thread overview]
Message-ID: <20141118170718.GH8154@bark> (raw)
In-Reply-To: <CAJfpegtG68g=dDi7j-WfhkuJidZRBg46vyuWg8CTrW3TrW_nYw@mail.gmail.com>

On Tue, Nov 18, 2014 at 03:28:03PM +0100, Miklos Szeredi wrote:
> [CC-ing mailing lists, Al and Linus for wider exposure]
> 
> This issue is this: Ubuntu and SUSE carry an "old" format of overlayfs
> while mainline has a "new" format.  The differences are:
> 
>  - whiteouts are represented differently (symlink + xattr in the old
> format, chardev in the new)
> 
>  - new one needs a "workdir" mount option, which points to a directory
> on the same filesystem as upperdir.  If upperdir was the root of the
> filesystem then it needs to be moved into a subdir to make space for
> the work directory.
> 
> Migrating from old to new is not a big issue, but Ubuntu people have
> expressed concerns about systems with mixed kernel versions and want
> to support the old format alongside the new.
> 
> This can all be done with out-of-tree code.
> 
> So from mainline we need two things:
> 
>   - when mounting distinguish between old and new format.
> 
>   - userspace can detect which formats are supported by the kernel.
> 
> If we'd have a different filesystem type for the old and new formats,
> then that would solve both (checking /proc/filesystems would indicate
> which one is supported).
> 
> Unfortunately that would mean having to change "overlayfs" type to
> something else in 3.18.  Question is, is there some sane name which
> would fit?  "overlayfs2" is perhaps the best, but I'm not overly
> enthusiastic about it.
> 
> Any other ideas?

ext4 makes use of feature flags in /sys/fs/ext4/features.  Perhaps we could
make use of this, say /sys/fs/overlayfs/features/{workdir,whiteout-chrdev},
or a even some kind of version in /sys/fs/overlayfs/version.

The presence of /sys/fs/overlayfs itself might be enought to assume the
presence of support for the new format.

-apw

  reply	other threads:[~2014-11-18 17:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18 14:28 How to cope with two incompatible overlayfs formats out in the wild Miklos Szeredi
2014-11-18 17:07 ` Andy Whitcroft [this message]
2014-11-19  1:59 ` Al Viro
2014-11-19  8:19   ` Miklos Szeredi
2014-11-19 14:29 ` Miklos Szeredi

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=20141118170718.GH8154@bark \
    --to=apw@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=neilb@suse.de \
    --cc=serge.hallyn@ubuntu.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.