On Thu, May 31, 2018 at 4:06 PM, bfields@xxxxxxxxxxxx <bfields@xxxxxxxxxxxx> wrote: > On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote: >> On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust >> <trondmy@xxxxxxxxxxxxxxx> wrote: >> > On Thu, 2018-05-31 at 14:55 +0200, Miklos Szeredi wrote: >> >> On Thu, May 31, 2018 at 2:47 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: >> >> > I'm still in strong disagreement with the model you are presenting >> >> > here. It is a client enforced model, which is not ever going to be >> >> > compatible with the NFS model. >> >> >> >> It's the only sane model that overlayfs can do. >> >> >> >> Think of it this way: creating an image file on NFS, formating it to >> >> ext4 and mounting it locally through the loop device is not going to >> >> be compatible with the NFS security model either. Should we care? >> > >> > Yes you should care because you are proposing that the simple act of >> > mounting through overlayfs will change who can access, read and modify >> > existing files from a NFS server. >> >> Only access/read: NFS can only be read-only layer. So it's impossible >> to actually modify a file on NFS through overlayfs. > > In addition to being read-only, I assume it's also unchanging? I wonder > why you'd want to use NFS at all for this case--sharing a read-only > ext4-formatted block device would seem more straightforward. Actually we could allow changes on the server side. Overlayfs sort of does this already (calls underlying fs's ->d_revalidate() from ovl_dentry_revalidate()). What's still needed is to detect rename by rechecking parent and d_name to match overlay dentry's parent and d_name. But a shared block dev could be used in most cases, I guess. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
