[316] in Athena_Backup_System
Re: Jonathon Weiss: Re: Minutes of 19 Sept Meeting
daemon@ATHENA.MIT.EDU (ted@MIT.EDU)
Fri Sep 27 11:05:52 1996
From: ted@MIT.EDU
To: athena-backup@MIT.EDU
In-Reply-To: Your message of "Thu, 26 Sep 1996 18:50:54 EDT."
<9609262250.AA02564@ops-5.MIT.EDU>
Date: Fri, 27 Sep 1996 11:05:08 EDT
> Here are some alternatives to think about:
>
> It seems that the vlserver interface supports a VL_GetAddrs
> call which gets the ip address of all file servers.
>
> We could fetch the address of all the fileservers, execute a
> gethostby address call for each address and then do the server name
> pattern match on the results.
>
> We then do a VL_ListAttributes for the selected server names;
> from there on we can pattern match any volume names.
Hmm. This allows support for something that I did not know was
possible, specifying (and perhaps pattern matching) by ip address. It
would be nice to have, but I'm not going to say we need it, since we
get by without it now and I hate to encourage feature creep.
Jonathon's specific example is of a dumpset that wants the server
pattern to match every server. I think in this case it makes sense to
make just one VL_ListAttributes call instead of several
VL_ListAttributes calls.
> VL_ListEntry at a time VS bulk fetch.
>
> VL_ListEntry returns one entry at a time and performs a full
> scan of the entire vldb. It provides the caller with information
> whch is equvialent to a cursor, allowing him to fetch subsequent
> entries. This implies the client makes one remote call per entry.
>
> For fetch by server or server partition, the vlserver essentially
> performs a full scan of the entire vldb to retireve matching vldb
> entries in one call. What you are saving here is the over head of
> issuing 20,000+ remote procedure calls to retrieve all volume entries.
>
> I think we should do some performance testing to determine what
> the impact is on each of the network, the client, and the vlservers.
I agree that, overall, the VL_ListAttrbiutes call produces the least
total load. I think the issue that performance testing needs to
address in this regard is how large an effect the call has on the
server, since the server is searching through the whole VLDB. Will
this impact other VLDB queries more than we can tolerate? I can see
that one reason to choose to use VL_ListEntry is that each single call
is so small that other queries should not be significantly affected.
--Ted
