Whamcloud - gitweb
LU-1422 cray: Cray platforms set the initial connection value to high
authorJames Simmons <uja.ornl@gmail.com>
Fri, 18 May 2012 17:44:07 +0000 (13:44 -0400)
committerOleg Drokin <green@whamcloud.com>
Thu, 7 Jun 2012 18:13:23 +0000 (14:13 -0400)
While testing imperative recovery it was observed that cray systems
had a noticable delay that did not happen on other systems. It was
discovered that the INITIAL_CONNECTION_TIMEOUT has set to a value
for the old Cray catamount systems which is not long valid and
now impacts recovery performace for both the IR and SR case. Also
this patch removes some catamount hacks from liblustre.

Signed-off-by: James Simmons <uja.ornl@gmail.com>
Change-Id: Ia6ff6e22886c49c861ad9469e675f38fe42d6fb4
Reviewed-on: http://review.whamcloud.com/2835
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Cory Spitz <spitzcor@cray.com>
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>

index 9411f04..3fe05d4 100644 (file)
@@ -136,18 +136,10 @@ int obd_alloc_fail(const void *ptr, const char *name, const char *type,
     miss the recovery window */
 #define CONNECTION_SWITCH_MAX min(50U, max(CONNECTION_SWITCH_MIN,obd_timeout))
 #define CONNECTION_SWITCH_INC 5  /* Connection timeout backoff */
-#ifndef CRAY_XT3
 /* In general this should be low to have quick detection of a system
    running on a backup server. (If it's too low, import_select_connection
    will increase the timeout anyhow.)  */
-/* ...but for very large systems (e.g. CRAY) we need to keep the initial
-   connect t.o. high (bz 10803), because they will nearly ALWAYS be doing the
-   connects for the first time (clients "reboot" after every process, so no
-   chance to generate adaptive timeout data. */
 /* The max delay between connects is SWITCH_MAX + SWITCH_INC + INITIAL */
index 3fa4d53..a602f12 100644 (file)
 #include "../lutil.h"
-#ifdef CRAY_XT3
-int _sysio_lustre_init(void)
-        /*
-         * This is an aweful HACK.  Basically the problem is on
-         * Catamount, the build system links in liblustre.a to
-         * all the test executables, and at this point its not
-         * clear how to modify the build system to prevent this
-         * from happening.  So providing our own call to 
-         * _sysio_lustre_init() that does nothing, prevents
-         * liblustre.a from initializing.
-         *
-         * Why is liblustre.a initializing a problem anyway.  Well
-         * this main() in this module calls init_obdclass(), as 
-         * well as the llite_lib.c's _sysio_lustre_init().  Two
-         * calls to init_obdclass() cause an assertion.  Secondly
-         * it doesn't even logically make sense, this is module
-         * does not need lustre file system functionality, it's 
-         * just the echo_tester.
-         * 
-         */
-        /*lprintf("--> THIS OVERRIDES liblustre.a INITIALIZATION <--\n");*/
-        return 0;
 extern int class_handle_ioctl(unsigned int cmd, unsigned long arg);
 static int liblustre_ioctl(int dev_id, unsigned int opc, void *ptr)
index 843fe41..d3a27c9 100644 (file)
@@ -4123,10 +4123,7 @@ wait_import_state() {
 # the value depends on configure options, and it is not stored in /proc.
 # obd_support.h:
-# #ifndef CRAY_XT3
-# #else
 request_timeout () {
     local facet=$1