After our meeting discussion today, I think that AXL_XFER_BEST should be updated to meet these requirements:
It should work for all file transfers (not just SSD -> GPFS).
The transfer mechanism should be detectable at runtime (looking for $BBPATH?). That way, if the BB server is down, it will not chose a BBAPI transfer. Currently it will chose the BBAPI if it detects the BBAPI libraries, which could be problematic at some sites.
Basically, AXL_XFER_BEST should be the easy-button "it will work with everything" choice. We might even want to consider naming it to the less misleading "AXL_XFER_DEFAULT", since AXL may not choose the "best" (fastest) API for your particular use case.
Along with this, maybe we should introduce a new AXL_XFER_NATIVE type that will chose whatever special transfer library is on the node (BBAPI or DataWarp), with the caveat that the user knows they must abide by the specific requirements of the native API (i.e only SSD -> GPFS transfers).
After our meeting discussion today, I think that
AXL_XFER_BEST
should be updated to meet these requirements:It should work for all file transfers (not just SSD -> GPFS).
The transfer mechanism should be detectable at runtime (looking for
$BBPATH
?). That way, if the BB server is down, it will not chose a BBAPI transfer. Currently it will chose the BBAPI if it detects the BBAPI libraries, which could be problematic at some sites.Basically,
AXL_XFER_BEST
should be the easy-button "it will work with everything" choice. We might even want to consider naming it to the less misleading "AXL_XFER_DEFAULT
", since AXL may not choose the "best" (fastest) API for your particular use case.Along with this, maybe we should introduce a new
AXL_XFER_NATIVE
type that will chose whatever special transfer library is on the node (BBAPI or DataWarp), with the caveat that the user knows they must abide by the specific requirements of the native API (i.e only SSD -> GPFS transfers).