Re: [nfsv4] GETATTR within an Absent File System in 5661

[Tom Haynes <[e-mail]>]

I guess I should save up questions until I finish a section!  :->

Or nevermind...


Tom Haynes wrote:
>
>      11.3. Getting Attributes for an Absent File System
>
>
>   When a file system is absent, most attributes are not available, but
>   it is necessary to allow the client access to the small set of
>   attributes that are available, and most particularly those that give
>   information about the correct current locations for this file system:
>   fs_locations and fs_locations_info.
>
>
>        11.3.1. GETATTR within an Absent File System
>
>
>   As mentioned above, an exception is made for GETATTR in that
>   attributes may be obtained for a filehandle within an absent file
>   system.  This exception only applies if the attribute mask contains
>   at least one attribute bit that indicates the client is interested in
>   a result regarding an absent file system: fs_locations,
>   fs_locations_info, or fs_status.  If none of these attributes is
>   requested, GETATTR will result in an NFS4ERR_MOVED error.
>
>
>
> I can see two other attributes which we might want to allow the client
> access to in order to determine if a file system was migrated:
>
> 1) fsid
>
> PUTFH {fileid} GETATTR {fsid}
>
> Allows the client to determine that a filesystem boundary was crossed.
>
> If the client isn't allowed to detect this, then it might have problems
> mangling the paths.
>
> 2) mounted_on_fileid
>
> And the client might want to check where to mount the new filesystem.
>
> Hmm, 2) is not as strong a need as 1).
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4