Re: Is IP address failover supported on the CIFS client?

[Andy Beal <andybeal623@xxxxxxxxx>]

Hi all,

Thanks for the quick replies! I'm definitely happy to experiment with some patches.

Regarding the DFS cache idea, do you think that would also be extensible to the Windows Failover Clustering use case as well (DNS A record with multiple IPs)? At the surface level, I'm imagining that the same hash table could map DNS names to all the possible IPs, along with the DNS record expiry time. While supporting DFS failover will be a huge win for HA using the CIFS client, over time I'd expect more and more architectures to leverage the newer, DNS-based solution as well.

Thanks!

Andy

On Wed, Aug 1, 2018 at 4:19 AM Steve French <smfrench@xxxxxxxxx> wrote:

Yes, your approach is worth pursuing

On Wed, Aug 1, 2018, 01:13 Aurélien Aptel <aaptel@xxxxxxxx> wrote:

I have thought a bit about how to implement this (we have a customer at
SUSE who requested this):

1) implement a DFS cache

We could add a global hashtable to map dfs paths to their targets, along
with an expiry time. The finer details of what to use and store should
be described in MS-DFSN.

Every time we need to do a dfs referal we lookup in the hashtable if the
path has already been resolved and is not expired we return the lists of
possible targets otherwise we issue the referal, store the results in
the hashtable and return them.

2) Replace existing code to use the cache DFS api we just implemented

3) In the reconnection code, reconnect to origin instead of target.

This is the tricky part.

When we mount a DFS target the superblock only stores the final
destination as if it was a regular mount. When that final target server
fails cifs.ko tries to reconnect but only to the final target instead of
the other possible results from the previously done DFS lookup.

So we could:
- store the origin(s?) so that we can do a DFS lookup again at reconnection
- implement some sort of reverse-lookup in the DFS cache

I'm not sure what the easiest way to go is when you take into account
links with 2+ jumps (eg AD -> Namespace Server -> final share).

Cheers,

--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)