Re: Make sm-notify faster if there are no servers to notify

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Dec 08, 2008 at 02:50:39PM -0500, Chuck Lever wrote:
> Hi Bruce-
>
> On Dec 5, 2008, at Dec 5, 2008, 9:42 PM, J. Bruce Fields wrote:
>> On Fri, Dec 05, 2008 at 01:41:32PM -0500, Chuck Lever wrote:
>>> On Dec 5, 2008, at 12:29 PM, J. Bruce Fields wrote:
>>>> How about adding an explicit fsync() of the state file (and parent
>>>> directory) to statd's first succesful creation of a statd record,
>>>> together with a comment explaining this?  So around about line 194  
>>>> in
>>>> utils/statd/monitor.c:sm_mon_1_svc()?
>>>>
>>>> In fact, we could delete the sync entirely and do the same before  
>>>> the
>>>> first notification, and then we wouldn't have to wait for the sync  
>>>> in
>>>> the case host records are present either....  (statd would, but
>>>> perhaps we could still get other work done in the mean time).
>>>>
>>>> (Am I missing something?)
>>>
>>> This all might work, but I think we're adding a lot of complexity as 
>>> a
>>> workaround.
>>
>> I think you mean the justification is too subtle--the code itself  
>> (just
>> a couple syncs or fsyncs) is pretty simple.
>
> Let me state it another way.  Your suggested redesign makes assumptions 
> about the order in which these operations are performed.  Can the code 
> provide any guarantee that this ordering is always true?  This may have 
> been feasible when rpc.statd did notification too, but these are now two 
> separate programs.  Can you think of a way of implementing this where the 
> ordering dependencies are coded instead of commented?

The existing code requires that we update the on-disk nsm state number
before doing notification or accepting statd calls.  That's the only
ordering I'd require.

Maybe I should try to write a patch.

--b.

>
> It would be significantly less fragile (ie immune to ordering problems  
> and long-term changes to system start-up and nfs-utils code) and simpler 
> to understand if sm-notify does whatever syncing it needs, and rpc.statd 
> does whatever syncing it needs.
>
> All I'm saying is this scheme may be easy to break by accident, and any 
> future problem here is probably not going to show up until someone  
> really needs this to work right.
>
>>> Someone should fix the real problem, which is the
>>> implementation of sync().
>>
>> I think you mean of fsync().  My understanding of past discussions on
>> the issue is that it's not really fixable on ext3, at least.  So
>> default setups will have this problem for a while.
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com