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 11:37:40 +0300	[thread overview]
Message-ID: <CAOQ4uxgicOnJvV-juNoi9pV+PCzyGqWU-=vrU=1Uq9-tUE+FrA@mail.gmail.com> (raw)
In-Reply-To: <CAJfpeguateThdqWPdF1P-OFuxYdrdgtz7dj-=ewBft-k2gDSdQ@mail.gmail.com>

On Fri, Jun 11, 2021 at 10:55 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Fri, 11 Jun 2021 at 09:31, Amir Goldstein <amir73il@gmail.com> wrote:
>
> >
> > 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.
>
> Makes sense.
>
> Not sure how you'd make it single byte and user friendly at the same
> time. I.e. how'd you represent +ia?.   Otherwise I'm fine with either.
>

I had not considered user friendliness.
I was thinking about the lower byte of i_flags.
I can go with text format as planned for xflags
but with no need for the fixed positions of letters.
This format will be compatible with chattr so easy
for script that "offline merge" overlay upper to lower.

Thanks,
Amir.

  reply	other threads:[~2021-06-11  8:38 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
2021-06-11  7:55                   ` Miklos Szeredi
2021-06-11  8:37                     ` Amir Goldstein [this message]
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='CAOQ4uxgicOnJvV-juNoi9pV+PCzyGqWU-=vrU=1Uq9-tUE+FrA@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).