lkml.org 
[lkml]   [2012]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 0/2] issues with NFS filesystems as lower layer
From
On Thu, Sep 6, 2012 at 5:56 PM, Andy Whitcroft <apw@canonical.com> wrote:
> During some testing here we discovered that we could not successfully
> use a NFS as the lower layer for overlayfs. There are two separate issues:
>
> Firstly when using an NFSv4 lower layer we tickle an issue when copying
> up the xattrs for the underlying file. NFS uses an xattr system.nfs4_acl
> which the upper layer will not store (ext4 for example). This triggers
> an EOPNOTSUPP error when trying to copy up the xattrs for the file,
> preventing the file being written. I am a little unclear as to whether it
> makes sense to generally ignore xattrs we cannot store in the upper layer,
> this is based on the assumption the person creating the mount knew what
> they were combining. The first patch (for discussion) following this
> email avoids this issue by ignoring the xattr if it is not storable.

I don't know much about NFSv4 ACL's but I think it may be incompatible
with POSIX ACLs in which case copying them up is not possible and
ignoring them should be the right thing to do.

>
> Secondly when using an NFSv3 R/O lower layer the filesystem permissions
> check refuses permission to write to the inode which prevents us from
> copying it up even though we have a writable upper layer. (With an ext4
> lower layer the inode check will succeed if the inode is writable even
> if the filesystem is not.) It is not clear what the right solution is
> here. One approach is to check the inode permissions only (avoiding the
> filesystem specific permissions op), but it is not clear we can rely on
> these for all underlying filesystems. Perhaps this check should only be
> used for NFS. Perhaps it needs to be a mount option. The second patch
> (for discussion) following this email implements this, using the inode
> permissions when the lowerlayer is read-only. This seems to work as
> expected in my limited testing.

I fear that will create an inconsistency between the read-only and the
non-read-only case, even though both should behave the same.

I think the cleanest would be to create a mount option to always use
generic_permission (on both the lower and the upper fs). That would
give us two, slightly different, operating modes but each would be
self consistent.

Thanks,
Miklos


\
 
 \ /
  Last update: 2012-09-07 09:21    [W:0.064 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site