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. 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? Is it not a problem to rely on an upper fs for modern systems that does not support RENAME_WHITEOUT? Thanks, Amir.
