[Pvfs2-developers] Distribution by hostname

[Sam Lang]

On Oct 10, 2006, at 2:18 PM, Bradley W Settlemyer wrote:

>
> Sam Lang wrote:
>
>> What are the benefits of those functions over something like:
>> PVFS_sys_dist_set_param(..., "io-server-mapping", &server_map);
>> I dislike the idea of adding interfaces that won't get much use,  
>> esp if we already have a generic mechanism for doing the same.
>> -sam
>
> Just so we're all clear on what was intended with that interface,  
> the idea is that distributions can overload the behaviour of the  
> underlying parameter setter.

The distribution _is_ the underlying parameter setter.  In the case  
of the simple stripe, if the strip-size wasn't provided with  
setparam, its the simple-stripe code that chooses the default.  The  
user of the system interfaces can overload that default, but the rest  
of the pvfs code doesn't know anything about it.

I don't want to go round and round with this, I'm just trying to keep  
things as user friendly as possible.  There's a clear design built  
into distributions: they're opaque to everyone but the distribution  
methods.  If possible, I think it would be good to keep it that way  
(just imagine how fun the request processing code would be if it  
accessed distribution fields directly).  As for the  
PVFS_sys_dist_setparam call, the way we use it in our code today is  
in setting the strip-size on the simple stripe distribution (from  
outside the system interfaces).  Setting a server list or number of  
servers via that call doesn't seem like its much of a stretch.

>
> For example, in the default provided functions, I checked the data  
> for overrun of the distribution data type, but it doesn't have any  
> support for an underfilled data type (for example, if an int is set  
> into an int64, that's probably going to lead to 32 bits of random  
> junk in the distribution parameter).  But that will work fine  
> (though perhaps precariously) for the default simple-stripe  
> distribution.

Yeah static type checking is lost with the void *. but is it worth  
adding rather specific interfaces to avoid that?

>
> The varstrip guys provided a parameter setter that parsed some a  
> string format.  So the current model is that each distribution  
> provides its own string format.  I'm not sure whether that's really  
> the best approach or not.

I view the underlying storage of the parameters and the interfaces to  
those parameters to be orthogonal.  Storing them as strings probably  
makes sense.  Making the caller sprintf into a string to create them  
doesn't (even if that's what's mpich does :-)).

-sam

>
> Cheers,
> brad
>