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. > > 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. > > Is it simple to implement RENAME_WHITEOUT for fuse/virtiofs? Trivial. > Is it not a problem to rely on an upper fs for modern systems > that does not support RENAME_WHITEOUT? Limited r/w overlay functionality is still available without whiteout/xattr support, so it could turn out to be something people already rely on. Can't tell without trying... Thanks, Miklos
