Re: [PATCH 4/4] ovl: alllow remote upper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux