Hi Bruce/Chuck/Trond,
Question for you: currently, the linux server replies back with
FS_LOCATIONS as a supported attribute. Yet if the client were to ask
it for FS_LOCATIONS (on a root of the filesystem), the server's reply
is a 0 value. I'm not finding anything in the spec that talks about
what the reply should (or shouldn't) be. Is it the client's
responsibility to interpret the 0 value reply as no other locations
are available. Or is this an invalid reply and there should be at
least the current IP present in the reply?
It's unclear to me what and how this situation should be solved: on
the server side or client side?
Thank you for your help.
On 11/22/21 10:46 AM, Olga Kornievskaia wrote:
> Hi Bruce/Chuck/Trond,
>
> Question for you: currently, the linux server replies back with
> FS_LOCATIONS as a supported attribute. Yet if the client were to ask
> it for FS_LOCATIONS (on a root of the filesystem), the server's reply
> is a 0 value. I'm not finding anything in the spec that talks about
> what the reply should (or shouldn't) be. Is it the client's
> responsibility to interpret the 0 value reply as no other locations
> are available. Or is this an invalid reply and there should be at
> least the current IP present in the reply?
>
> It's unclear to me what and how this situation should be solved: on
> the server side or client side?
I found this from section 11.9 in RFC 5661:
When the fs_locations attribute is interrogated and there are no
alternate file system locations, the server SHOULD return a zero-
length array of fs_location4 structures, together with a valid
fs_root.
seems like server is doing the right thing.
-Dai
>
> Thank you for your help.