Hi Trond, Anna, Steve,
For kAFS, I'm writing something to allow the in-kernel DNS resolver be able to
ask for a server list (eg. the list of VL servers in an AFS cell) and get back
a list of servers and the addresses associated with each server.
This would be requested by passing an "srv=<version>" option in the callout
info.
The payload handed to the kernel currently looks like something assembled from
the data obtained from a bunch of SRV records that have been further looked up
to A or AAAA.
In the kernel it might get parsed to something like:
struct address {
union {
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
};
};
struct server {
unsigned short port;
unsigned short pref; // From SRV
unsigned short weight; // From SRV
unsigned char ipproto; // IPPROTO_*
unsigned int nr_addrs; // May be 0
struct address *addrs;
};
struct server_list {
unsigned int nr_servers;
struct server servers[];
};
Is this something that NFS or CIFS (or anything else for that matter) could
find useful?
I also have this loading information from a configuration file as a
backup/override of the DNS. Could that also be useful to NFS/CIFS?
David
David Howells <[email protected]> writes:
> The payload handed to the kernel currently looks like something assembled from
> the data obtained from a bunch of SRV records that have been further looked up
> to A or AAAA.
I was wondering recently if the current kernel API lets you to access
all A/AAAA records in case a same domain uses multiple ones. It seems
not, is this correct?
> In the kernel it might get parsed to something like:
>
> struct address {
> union {
> struct sockaddr_in sin;
> struct sockaddr_in6 sin6;
> };
> };
You probably want struct sockaddr_storage here.
>
> struct server {
> unsigned short port;
> unsigned short pref; // From SRV
> unsigned short weight; // From SRV
> unsigned char ipproto; // IPPROTO_*
> unsigned int nr_addrs; // May be 0
> struct address *addrs;
> };
>
> struct server_list {
> unsigned int nr_servers;
> struct server servers[];
> };
>
> Is this something that NFS or CIFS (or anything else for that matter) could
> find useful?
That sounds useful indeed. I'm currently thinking about a failover
mechanism for DFS (symbolic links across servers in cifs). The protocol
supports multiple possible targets for the link in case one is down. The
targets are usually using hostnames so with your change we could have a
second layer of failover at the DNS level.
> I also have this loading information from a configuration file as a
> backup/override of the DNS. Could that also be useful to NFS/CIFS?
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)
Aurélien Aptel <[email protected]> wrote:
> > The payload handed to the kernel currently looks like something assembled
> > from the data obtained from a bunch of SRV records that have been further
> > looked up to A or AAAA.
>
> I was wondering recently if the current kernel API lets you to access
> all A/AAAA records in case a same domain uses multiple ones. It seems
> not, is this correct?
It does permit this. kAFS currently uses it. Just don't pass "ipv4" or
"ipv6" in the callout info as those impose restrictions.
David
On Thu, Sep 13, 2018 at 1:39 AM Aur=C3=A9lien Aptel <[email protected]> wrote=
:
>
> David Howells <[email protected]> writes:
> > Is this something that NFS or CIFS (or anything else for that matter) c=
ould
> > find useful?
>
> That sounds useful indeed. I'm currently thinking about a failover
> mechanism for DFS (symbolic links across servers in cifs). The protocol
> supports multiple possible targets for the link in case one is down. The
> targets are usually using hostnames so with your change we could have a
> second layer of failover at the DNS level.
>
> > I also have this loading information from a configuration file as a
> > backup/override of the DNS. Could that also be useful to NFS/CIFS?
>
> Cheers,
> --
> Aur=C3=A9lien Aptel / SUSE Labs Samba Team
Yes - the idea that Aurelien notes above is VERY important for some
improving some recovery scenarios, and if this helps us get there
faster it will greatly improve reliability of some common user scenarios.
--=20
Thanks,
Steve
Aurélien Aptel <[email protected]> wrote:
> > struct address {
> > union {
> > struct sockaddr_in sin;
> > struct sockaddr_in6 sin6;
> > };
> > };
>
> You probably want struct sockaddr_storage here.
It's actually now:
struct address {
u8 family;
union {
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
};
};
And note that this is schematic not actual. It's not actually a C union.
ipv4 and ipv6 addresses take up different amounts of space in the binary blob.
One of the criteria is that the blob should be as small as possible since it
gets cached by the kernel as is (as the payload of a key) and only gets looked
at when it gets parsed.
David