On Mon, Mar 19, 2012 at 03:00:57PM -0400, Chuck Lever wrote:
>
> On Mar 19, 2012, at 2:54 PM, J. Bruce Fields wrote:
>
> > On Mon, Mar 19, 2012 at 02:42:30PM -0400, Chuck Lever wrote:
> >>
> >> On Mar 19, 2012, at 2:39 PM, J. Bruce Fields wrote:
> >>
> >>> On Mon, Mar 19, 2012 at 02:29:46PM -0400, Chuck Lever wrote:
> >>>>
> >>>> On Mar 19, 2012, at 2:27 PM, J. Bruce Fields wrote:
> >>>>> That's also not this case, sorry, this time with all the conditions:
> >>>>>
> >>>>> - if the nfs_client_id4 is the same, and
> >>>>> - if the flavor is auth_sys, and
> >>>>> - if the client IP address is different,
> >>>>> - then return NFS4ERR_INUSE.
> >>>>
> >>>> This still breaks for multi-homed servers and UCS clients. The client IP address can be different depending on what server IP address the client is accessing, but all the other parameters are the same.
> >>>
> >>> OK. So probably there's nothing we can do to help here.
> >>>
> >>> As a bandaid maybe a rate-limited log message ("clientid X now in use
> >>> from IP Y") might help debug these things....
> >>
> >> Hm, OK. That implies your server implementation assumes that a clientid4 maps to exactly one client IP address at a time.
> >
> > OK, agreed. So how about something like "state for client X previously
> > established from IP Y now cleared from IP Z" ??
> >
> > (Assuming it's only the I-just-rebooted setclientid case that's likely
> > to be the sign of a problem.)
>
> We would see that only in the case where the boot verifier and the client IP change at the same time. That can happen legitimately, too, if the client has a dynamically assigned IP address. Maybe this event is only interesting if it happens more than once during the same second.
"Warning: IP addresses Y and Z currently appear to be in a bitter
struggle over client id X"....
That may be getting complicated enough to not be worth it except as a
part of some more general statistics.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
