On Fri, Jan 31, 2020 at 5:38 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Fri, Jan 31, 2020 at 4:30 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Fri, Jan 31, 2020 at 1:51 PM Miklos Szeredi <mszeredi@xxxxxxxxxx> 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.
