1. 15 Oct, 2014 1 commit
  2. 13 Oct, 2014 1 commit
  3. 09 Oct, 2014 1 commit
  4. 30 Sep, 2014 4 commits
  5. 29 Sep, 2014 1 commit
  6. 25 Sep, 2014 2 commits
  7. 19 Sep, 2014 1 commit
  8. 15 Sep, 2014 1 commit
  9. 12 Sep, 2014 1 commit
    • Steven Murray's avatar
      Fixed bug where putting down a running drive crashes tapeserverd · 4bb07abb
      Steven Murray authored
      Vlado found this bug whilst running tapserverd with real tape hardware.
      Mounts last long enough with real hardware for an operator to easily
      use "tpconfig down" on a running drive.
      
      The tapserverd process was not handling the WAIT_DOWN state correctly
      and was throwing an unexpected exception that in turn caused the process
      to crash due to the resulting abort signal.
      
      The tapserverd process was not handling the WAIT_DOWN state correctly
      due to some over simplifications I made to the architecture of
      tapeserverd.
      4bb07abb
  10. 09 Sep, 2014 2 commits
  11. 19 Aug, 2014 1 commit
  12. 03 Jul, 2014 2 commits
  13. 24 Jun, 2014 1 commit
  14. 07 May, 2014 1 commit
  15. 01 Oct, 2013 1 commit
    • Steven Murray's avatar
      bug #102728: RFE: Develop Oracle ACS compatible executables for rmcd · a6803f8e
      Steven Murray authored
      This commit does two things.  Firstly it adds the first version of the source
      code for the executables to help the rmcd daemon to work with Oracle ACS
      compatible tape-libraries.  Secondly it refactors and cleans up some of the
      rmcd daemon code.
      
      Please note that the source code of the binaries to help the rmcd work with
      Oracle ACS tape-libraries is neither compiled or packaged into rpms.  Therefore
      there will be no affect on the current 2.1.14 release concerning these
      executables.
      a6803f8e
  16. 19 Jul, 2013 1 commit
  17. 09 Aug, 2011 1 commit
  18. 01 Aug, 2011 1 commit
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · 7aeaa7cc
      Steven Murray authored
      After further reverse engineering rtcpd it became apparent that there should
      only be one configuration parameter to specify which of the following 3 possible
      tape-flush behaviours the tapebridged and rtcpd daemons should follow:
      
        * N_FLUSHES_PER_FILE
        * ONE_FLUSH_PER_FILE
        * ONE_FLUSH_PER_N_FILES
      
      This commit adds the following tapebridge configuration parameter, which today
      is ignored:
      
        TAPEBRIDGE TAPEFLUSHMODE N_FLUSHES_PER_FILE
      
      More importantly and the real reason for this commit is the value of this
      configuration parameter is now passed from the tapebridged daemon to the rtcpd
      daemon via the tapeFlushMode member of the newly updated TAPEBRIDGE_CLIENTINFO2
      message:
      
      typedef struct {
        uint32_t volReqId;
        uint32_t bridgeCallbackPort;
        uint32_t bridgeClientCallbackPort;
        uint32_t clientUID;
        uint32_t clientGID;
        uint32_t tapeFlushMode;
        uint64_t maxBytesBeforeFlush;
        uint64_t maxFilesBeforeFlush;
        char     bridgeHost[CA_MAXHOSTNAMELEN+1];
        char     bridgeClientHost[CA_MAXHOSTNAMELEN+1];
        char     dgn[CA_MAXDGNLEN+1];
        char     drive[CA_MAXUNMLEN+1];
        char     clientName[CA_MAXUSRNAMELEN+1];
      } tapeBridgeClientInfo2MsgBody_t;
      
      Please note that the TAPEBRIDGE_CLIENTINFO2 has not been released in any version
      of CASTOR and is therefore subject to change until the next release where it
      will be frozen.
      7aeaa7cc
  19. 24 Jun, 2011 1 commit
  20. 13 May, 2011 1 commit
  21. 12 May, 2004 1 commit