Project

General

Profile

Actions

Bug #5126

open

nfs4: stat does not trigger mirror mount

Added by Simon K over 7 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2014-09-03
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

I’m using nfs4 mirror mounts. The directory data is an empty (currently not mounted) mount point within a shared tree.

Please note that the inode number and device id change after using ls:

> stat data
  File: `data'
  Size: 4               Blocks: 5          IO Block: 8192   directory
Device: 8e8231fh/149431071d     Inode: 6           Links: 4
Access: (0500/dr-x------)  Uid: ( 1000/   httpd)   Gid: ( 1100/     www)
Access: 2012-04-04 13:11:47.000000000 +0200
Modify: 2013-02-08 10:06:41.699166511 +0100
Change: 2014-05-20 15:59:42.905885625 +0200

> ls data
public  users

> stat data
  File: `data'
  Size: 4               Blocks: 5          IO Block: 8192   directory
Device: 8e82325h/149431077d     Inode: 3           Links: 4
Access: (0500/dr-x------)  Uid: ( 1000/   httpd)   Gid: ( 1100/     www)
Access: 2012-04-04 13:11:47.000000000 +0200
Modify: 2013-02-08 10:06:41.699166511 +0100
Change: 2014-05-20 15:59:42.905885625 +0200

ls triggers the mount. stat not.

I’m wondering if the function nfs4_trigger_getattr should always trigger a mount. I think stat should always return reliable information.

Actions #1

Updated by Marcel Telka over 7 years ago

If you'll try the similar test with automounter (instead of mirror mounts), you'll find that the behavior is similar there. It looks like the mirror mount was implemented to behave similarly as automounter. The question is what is the correct behavior.

In any case, if the mirror mount case is going to be fixed (provided it is the right thing to do), we should think about the automounter fix as well.

Actions

Also available in: Atom PDF