linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>, Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH 3/3] ovl: use persistent s_uuid with index=on
Date: Thu, 6 Jul 2023 20:49:05 +0300	[thread overview]
Message-ID: <CAOQ4uxgfTTQ5VAYTrQw0jkFVhiBRvTZ7hL9HU1MoPSCDCd_p6g@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxhh6fh8spdBSxaPQCMK8OKGLjvi=JvwAM0J9vZaEeAgZg@mail.gmail.com>

On Thu, Jul 6, 2023 at 1:14 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Jul 6, 2023 at 10:19 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Tue, Apr 25, 2023 at 4:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > With index=on, overlayfs instances are non-migratable, meaning that
> > > the layers cannot be copied without breaking the index.
> > >
> > > So when indexdir exists, store a persistent uuid in xattr on the
> > > indexdir to give the overlayfs instance a persistent identifier.
> > >
> > > This also makes f_fsid persistent and more reliable for reporting
> > > fid info in fanotify events.
> > >
> > > With mount option uuid=nogen, a persistent uuid is not be initialized
> > > on indexdir, but if a persistent uuid already exists, it will be used.
> > >
> >
> > This behavior (along with the grammatical mistakes) was changed in
> > https://github.com/amir73il/linux/commits/ovl_encode_fid
> >
> > uuid=off or uuid=null both set ovl fsid to null regardless of persistent
> > uuid xattr.
> >
>
> Sorry, that was meant to say "set ovl uuid to null..."
> when ovl uuid is null then ovl fsid is not null, it is the fsid of the
> uppermost fs.
>
> This creates a dilemma wrt backward compat.
>
> With index=off, the mounter has a choice between two sub-optimal options:
> 1. persistent ovl fsid (of upper fs)
> 2. unique ovl fsid (from random uuid)
>
> If we change the default from legacy (1) to unique (2), that
> could also break systems that rely on the persistent ovl fsid
> of existing overlayfs layers.
>
> With index=on, the choice is between:
> 1. persistent ovl fsid (of upper fs)
> 2. persistent and unique ovl fsid (from uuid xattr)
>
> option (2) is superior, but still could break existing systems
> that rely on (1) being persistent.
>
> The decision to tie uuid xattr to the index dir and index=on
> was rationalized in the commit message, but persistent and
> unique fsid could also be implemented regardless of index=on.
>
> I think I may have found a dignified way out of this mess:
> - In ovl_fill_super(), check impure xattr on upper root dir
> - If impure xattr does not exist (very likely new overlay),
>   uuid_gen() and write the persistent uuid xattr on upper fs root
> - If uuid xattr is written or already exists, use that to initialize
>   s_uuid otherwise, leave it null
> - in ovl_statfs(), override the upper fs fsid, only if ovl uuid is non-null
>
> This gives:
> 1. Old overlayfs deployments retain old behavior wrt null uuid
>     and upper fsid, as long as they have had at least one subdir
>     of root copied up or looked up to trigger ovl_fix_origin()
> 2. New overlayfs deployments always generate and use a unique
>     and persistent uuid/fsid
> 3. mount option uuid=off/null (*) can be used to retain legacy behavior
>     on old/new overlayfs deployments (for whatever reason) and ignore
>     existing persistent uuid xattr
> 4. mount option uuid=on can be used to force new behavior on an
>     existing overlayfs with impure xattr and without uuid xattr
>
> (*) uuid=off was originally introduced for the use case of copied layers.
>      That is similar to the use case of copying disk images and dropping
>      the old persistent ovl uuid makes sense in that case.
>
> I will try to write this up.
>

OK, this is what I got in overlayfs.rst:

UUID and fsid
-------------

The UUID of overlayfs instance itself and the fsid reported by statfs(2) are
controlled by the "uuid" mount option, which supports these values:

- "null":
    UUID of overlayfs in null, fsid is taken from upper most fs.
- "off":
    UUID of overlayfs in null, fsid is taken from upper most fs
    and UUID of underlying layers not checked.
- "on":
    UUID of overlayfs in generated on first mount used to report a unique fsid.
    If upper filesystem supports xattrs, the UUID is stored in xattr
    "trusted.overlay.uuid", making the fsid unique and persistent.
- "auto": (default)
    Upgrade to "uuid=on" on first time mount of new overlay filesystem.
    Downgrade to "uuid=null" for existing overlay filesystems that were never
    mounted with "uuid=on".

Pushed to:
https://github.com/amir73il/linux/commits/ovl_encode_fid

Will post next week.

Thanks,
Amir.

      reply	other threads:[~2023-07-06 17:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 13:22 [RFC][PATCH 0/3] Prepare for supporting more filesystems with fanotify Amir Goldstein
2023-04-25 13:22 ` [RFC][PATCH 1/3] ovl: support encoding non-decodeable file handles Amir Goldstein
2023-07-06  7:27   ` Amir Goldstein
2023-04-25 13:22 ` [RFC][PATCH 2/3] ovl: report a per-instance f_fsid by default Amir Goldstein
2023-04-25 13:22 ` [RFC][PATCH 3/3] ovl: use persistent s_uuid with index=on Amir Goldstein
2023-07-06  7:19   ` Amir Goldstein
2023-07-06 10:14     ` Amir Goldstein
2023-07-06 17:49       ` Amir Goldstein [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=CAOQ4uxgfTTQ5VAYTrQw0jkFVhiBRvTZ7hL9HU1MoPSCDCd_p6g@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --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 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).