From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f179.google.com ([209.85.215.179]:42547 "EHLO mail-pg1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727869AbeIMDds (ORCPT ); Wed, 12 Sep 2018 23:33:48 -0400 MIME-Version: 1.0 References: <17451.1536750676@warthog.procyon.org.uk> <28796.1536787099@warthog.procyon.org.uk> In-Reply-To: <28796.1536787099@warthog.procyon.org.uk> From: Steve French Date: Wed, 12 Sep 2018 17:27:02 -0500 Message-ID: Subject: Re: Making the in-kernel DNS resolver handle server lists To: David Howells Cc: CIFS , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Sep 12, 2018 at 4:18 PM David Howells wrote: > > Steve French wrote: > > > Yes - this could be very useful for cifs (SMB3) in processing DFS > > (global namespace) referrals and also in Witness protocol > > redirections, as well as some reconnect scenarios > > Would the data format I outlined be sufficient for you? > > > (especially when low in memory when upcalls could be risky) > > Ummm... It's still upcalling - but a single upcall to fetch a block of > associated servers and all their addresses. In a reconnect scenario - anything we can do to make it more likely reconnect works (especially with all of the failover, clustering and redirections mechanisms in SMB3 and later) and can resolve the new host is good ... so yes even if upcall as long as less likely to hang ... this is good -- Thanks, Steve