This function call was being optimized out during nfs_fhget(), leading
to situations where we have a valid fileid but still want to use the
mounted_on_fileid. For example, imagine we have our server configured
like this:
server % df
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 9.1G 6.5G 1.9G 78% /
/dev/vdb1 487M 2.3M 456M 1% /exports
/dev/vdc1 487M 2.3M 456M 1% /exports/vol1
/dev/vdd1 487M 2.3M 456M 1% /exports/vol2
If our client mounts /exports and tries to do a "chown -R" across the
entire mountpoint, we will get a nasty message warning us about a circular
directory structure. Running chown with strace tells me that each directory
has the same device and inode number:
newfstatat(AT_FDCWD, "/nfs/", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
newfstatat(4, "vol1", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
newfstatat(4, "vol2", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
With this patch the mounted_on_fileid values are used for st_ino, so the
directory loop warning isn't reported.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfs/inode.c | 5 +++--
fs/nfs/internal.h | 2 --
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 4bffe63..2211f6b 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -352,8 +352,9 @@ nfs_fhget(struct super_block *sb, struct nfs_fh *fh, struct nfs_fattr *fattr, st
nfs_attr_check_mountpoint(sb, fattr);
- if (((fattr->valid & NFS_ATTR_FATTR_FILEID) == 0) &&
- !nfs_attr_use_mounted_on_fileid(fattr))
+ if (nfs_attr_use_mounted_on_fileid(fattr))
+ fattr->fileid = fattr->mounted_on_fileid;
+ else if ((fattr->valid & NFS_ATTR_FATTR_FILEID) == 0)
goto out_no_inode;
if ((fattr->valid & NFS_ATTR_FATTR_TYPE) == 0)
goto out_no_inode;
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index efaa31c..b6f34bf 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -31,8 +31,6 @@ static inline int nfs_attr_use_mounted_on_fileid(struct nfs_fattr *fattr)
(((fattr->valid & NFS_ATTR_FATTR_MOUNTPOINT) == 0) &&
((fattr->valid & NFS_ATTR_FATTR_V4_REFERRAL) == 0)))
return 0;
-
- fattr->fileid = fattr->mounted_on_fileid;
return 1;
}
--
2.1.3
On Tue, Dec 9, 2014 at 4:19 PM, Anna Schumaker
<[email protected]> wrote:
> This function call was being optimized out during nfs_fhget(), leading
> to situations where we have a valid fileid but still want to use the
> mounted_on_fileid. For example, imagine we have our server configured
> like this:
>
> server % df
> Filesystem Size Used Avail Use% Mounted on
> /dev/vda1 9.1G 6.5G 1.9G 78% /
> /dev/vdb1 487M 2.3M 456M 1% /exports
> /dev/vdc1 487M 2.3M 456M 1% /exports/vol1
> /dev/vdd1 487M 2.3M 456M 1% /exports/vol2
>
> If our client mounts /exports and tries to do a "chown -R" across the
> entire mountpoint, we will get a nasty message warning us about a circular
> directory structure. Running chown with strace tells me that each directory
> has the same device and inode number:
>
> newfstatat(AT_FDCWD, "/nfs/", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
> newfstatat(4, "vol1", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
> newfstatat(4, "vol2", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
So is the problem here that these are inodes that actually represent
mountpoints? I.e. we've mounted /exports, but have not yet deferenced
/exports/vol1 and /exports/vol2, but those will be automounted if we
do something like a 'ls /exports/vol1/'?
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Tue, Dec 9, 2014 at 5:01 PM, Trond Myklebust
<[email protected]> wrote:
>
> On Tue, Dec 9, 2014 at 4:19 PM, Anna Schumaker
> <[email protected]> wrote:
> > This function call was being optimized out during nfs_fhget(), leading
> > to situations where we have a valid fileid but still want to use the
> > mounted_on_fileid. For example, imagine we have our server configured
> > like this:
> >
> > server % df
> > Filesystem Size Used Avail Use% Mounted on
> > /dev/vda1 9.1G 6.5G 1.9G 78% /
> > /dev/vdb1 487M 2.3M 456M 1% /exports
> > /dev/vdc1 487M 2.3M 456M 1% /exports/vol1
> > /dev/vdd1 487M 2.3M 456M 1% /exports/vol2
> >
> > If our client mounts /exports and tries to do a "chown -R" across the
> > entire mountpoint, we will get a nasty message warning us about a circular
> > directory structure. Running chown with strace tells me that each directory
> > has the same device and inode number:
> >
> > newfstatat(AT_FDCWD, "/nfs/", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
> > newfstatat(4, "vol1", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
> > newfstatat(4, "vol2", {st_dev=makedev(0, 38), st_ino=2, ...}) = 0
>
> So is the problem here that these are inodes that actually represent
> mountpoints? I.e. we've mounted /exports, but have not yet deferenced
> /exports/vol1 and /exports/vol2, but those will be automounted if we
> do something like a 'ls /exports/vol1/'?
Yes, the chown will work after automounting each directory.
Anna
>
>
> --
> Trond Myklebust
>
> Linux NFS client maintainer, PrimaryData
>
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html