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: Miklos Szeredi <mszeredi@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 4/4] ovl: alllow remote upper
Date: Fri, 31 Jan 2020 17:50:33 +0200	[thread overview]
Message-ID: <CAOQ4uxificaCG4uVRh94WC-nSNbGSqtmNt6Bx92j1chF_Khpmw@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegvMz-nHOb3GkoU_afqRrBKt-uvOXL6GxWLa3MVhwNGLpg@mail.gmail.com>

On Fri, Jan 31, 2020 at 5:38 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Fri, Jan 31, 2020 at 4:30 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 1:51 PM Miklos Szeredi <mszeredi@redhat.com> wrote:
> > >
> > > No reason to prevent upper layer being a remote filesystem.  Do the
> > > revalidation in that case, just as we already do for lower layers.
> > >
> >
> > No reason to prevent upper layer from being a remote filesystem, but
> > the !remote criteria for upper fs kept away a lot of filesystems from
> > upper. Those filesystems have never been tested as upper and many
> > of them are probably not fit for upper.
> >
> > The goal is to lift the !remote limitation, not to allow for lots of new
> > types of upper fs's.
> >
> > What can we do to minimize damages?
> >
> > We can assert that is upper is remote, it must qualify for a more strict
> > criteria as upper fs, that is:
> > - support d_type
> > - support xattr
> > - support RENAME_EXCHANGE|RENAME_WHITEOUT
> >
> > I have a patch on branch ovl-strict which implements those restrictions.
>
> Sounds good.  Not sure how much this is this going to be a
> compatibility headache.  If it does, then we can conditionally enable
> this with a config/module option.
>

No headache at all:
- For now, do not change criteria for !remote fs
- Only remote fs needs to meet the most strict criteria
- We can add the 'strict' config later if we want impose
  same criteria also for local fs

> >
> > Now I know fuse doesn't support RENAME_WHITEOUT, but it does
> > support RENAME_EXCHANGE, which already proves to be a very narrow
> > filter for remote fs: afs, fuse, gfs2.
> > Did not check if afs, gfs2 qualify for the rest of the criteria.
> >

I checked - afs has d_automount and gfs2 is d_hash.
They do not qualify as any layer.

> > Is it simple to implement RENAME_WHITEOUT for fuse/virtiofs?
>
> Trivial.
>

So that leaves only fuse after implementing RENAME_WHITEOUT.
We are back in control ;-)

Thanks,
Amir.

  reply	other threads:[~2020-01-31 15:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 11:50 [PATCH 0/4] ovl: allow virtiofs as upper Miklos Szeredi
2020-01-31 11:50 ` [PATCH 1/4] ovl: restructure dentry revalidation Miklos Szeredi
2020-01-31 11:50 ` [PATCH 2/4] ovl: separate detection of remote upper layer from stacked overlay Miklos Szeredi
2020-01-31 11:50 ` [PATCH 3/4] ovl: decide if revalidate needed on a per-dentry bases Miklos Szeredi
2020-01-31 14:53   ` Amir Goldstein
2020-01-31 15:15     ` Miklos Szeredi
2020-01-31 11:50 ` [PATCH 4/4] ovl: alllow remote upper Miklos Szeredi
2020-01-31 15:29   ` Amir Goldstein
2020-01-31 15:38     ` Miklos Szeredi
2020-01-31 15:50       ` Amir Goldstein [this message]
2020-01-31 16:05         ` Miklos Szeredi
2020-02-04 14:59   ` Vivek Goyal
2020-02-04 16:16     ` Miklos Szeredi
2020-02-04 17:02       ` Amir Goldstein
2020-02-04 18:42         ` Vivek Goyal
2020-02-04 19:11           ` Amir Goldstein
2020-02-04 19:16             ` Miklos Szeredi
2020-02-20  7:52         ` Amir Goldstein
2020-02-20 20:00           ` Amir Goldstein
2020-03-14 13:16             ` Amir Goldstein
2020-03-16 17:54               ` Vivek Goyal
2020-03-16 19:02                 ` Amir Goldstein
2020-03-16 19:40                   ` Vivek Goyal
2020-03-18 13:36                   ` unionmount testsuite with upper virtiofs Amir Goldstein
2020-03-19 21:40                     ` Vivek Goyal

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=CAOQ4uxificaCG4uVRh94WC-nSNbGSqtmNt6Bx92j1chF_Khpmw@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    --cc=vgoyal@redhat.com \
    /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).