linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Chengguang Xu <cgxu519@mykernel.net>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH] ovl: consistent behavior for immutable/append-only inodes
Date: Fri, 11 Jun 2021 10:31:07 +0300	[thread overview]
Message-ID: <CAOQ4uxiHyd4iRxgtDGorNK8fzBJgViUXxgAtS7nfAdHMQeiAew@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjXWWmqFRs3GoyruQ1PUYOE7DiTVqqMFP_RkU7mo7GuaQ@mail.gmail.com>

On Wed, Jun 9, 2021 at 10:57 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Wed, Jun 9, 2021 at 10:28 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Wed, 9 Jun 2021 at 08:08, Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Tue, Jun 8, 2021 at 9:20 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > >
> > > > On Tue, 8 Jun 2021 at 17:33, Amir Goldstein <amir73il@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jun 8, 2021 at 5:49 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > > > >
> > > > > > On Tue, 8 Jun 2021 at 16:37, Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > > > > > > While you are here, do you think that will be sufficient for the on-disk format
> > > > > > > of overlay.xflags?
> > > > > > >
> > > > > > > struct ovl_xflags {
> > > > > > >         __le32 xflags;
> > > > > > >         __le32 xflags_mask;
> > > > > > > }
> > > > > >
> > > > > > I think I'd prefer a slightly more complex, but user friendlier
> > > > > > "+i,-a,..." format.
> > > > > >
> > > > >
> > > > > OK, but since this is not a merge, we'd only need:
> > > > > overlay.xflags = "ia..."
> > > > >
> > > > > Which is compatible with the format of:
> > > > > chattr =<xflags> <file>
> > > >
> > > > Fine.   Not sure what xflags_mask would be useful for in your proposal, though.
> > > >
> > >
> > > The idea was that in the context of fileattr_get(), any specific xflag
> > > value can be one of: SET, CLEAR, REAL.
> > >
> > > For most inodes all flags are REAL (no xflags xattr)
> > > All flags but the 4 in OVL_FS_XFLAGS_MASK are always REAL
> > > (i.e. taken from fileattr_get() on real inode).
> > >
> > > If we ever decide to extend OVL_FS_XFLAGS_MASK, say to include
> > > DIRSYNC, then an upper inode with DIRSYNC that was in state
> > > REAL before upgrade would become CLEAR after upgrade unless
> > > we kept the old xflags_mask in xattr.
> > >
> > > With the string format, this is not a concern.
> > > Therefore, I like the string format better.
> >
> > Hmm, so if the attribute letters would have fixed places in the string
> > and clear attributes would be represented by a space or a "-" then
> > that would be similarly extensible.   Just having a list of set
> > attribute letters would not allow having three states.
> >
>
> Right. Will do that.
>

Taking a step back.

The main problem this is trying to solve is losing persistent inode flags
on copy-up.

If this was just NOATIME and SYNC the solution would have been
simple - copy up the flags along with other metadata we copy up.

We wouldn't even need to limit ourselves to the 4 vfs inode flags
in ovl_copyflags(). We could add the the copied up flags more
fs specific flags that we know to be safe and rational to copy
such as NOCOW, NODUMP and DIRSYNC.

The secondary problem is that copying IMMUTABLE/APPEND
to upper inode on copy up is not an option, so the solution is to
store those properties in an xattr.

I think we should split the solution to the primary and secondary
problems and avoid an over-designed generic future extendable
xflags xattr feature.

So I am leaning towards a more focused solution for
IMMUTABLE/APPEND in the form of either two boolean
xattr overlay.{immutable,appendonly} or one single bytes
xattr overlay.protected.

Thanks,
Amir.

  reply	other threads:[~2021-06-11  7:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06 14:46 Amir Goldstein
2021-06-08 13:52 ` Miklos Szeredi
2021-06-08 14:37   ` Amir Goldstein
2021-06-08 14:49     ` Miklos Szeredi
2021-06-08 15:33       ` Amir Goldstein
2021-06-08 18:20         ` Miklos Szeredi
2021-06-09  6:08           ` Amir Goldstein
2021-06-09  7:28             ` Miklos Szeredi
2021-06-09  7:57               ` Amir Goldstein
2021-06-11  7:31                 ` Amir Goldstein [this message]
2021-06-11  7:55                   ` Miklos Szeredi
2021-06-11  8:37                     ` Amir Goldstein
2021-06-11  8:39                       ` 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=CAOQ4uxiHyd4iRxgtDGorNK8fzBJgViUXxgAtS7nfAdHMQeiAew@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=cgxu519@mykernel.net \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --subject='Re: [PATCH] ovl: consistent behavior for immutable/append-only inodes' \
    /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

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