1. 22 Sep, 2011 1 commit
  2. 07 Sep, 2011 2 commits
  3. 16 Aug, 2011 1 commit
  4. 10 Aug, 2011 1 commit
  5. 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
  6. 27 Jul, 2011 2 commits
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · 9b9847c6
      Steven Murray authored
      This commit modifies the tapebridged/rtcpd protocol that is internal to a
      tape-server.  The new version of the protocol is now capable of supporting
      buffered tape-marks, though the version of rtcpd in this commit still only
      supports at best one synchronised tape-mark per file, i.e. it does not support
      buffered-tape marks over more than one file.
      
      The change with respect to the previous version of to the tapebridged/rtcpd
      protocol is simple.  When the rtcpd daemon knows that its client is is the
      tapebridged daemon it now sends an explicit TAPEBRIDGE_FLUSHEDTOTAPE message to
      the tapebridged daemon when it can guarantee one or more files have been
      flushed to tape.  The tapebridge daemon will now only send
      FileMigratedNotification messages to the tapegatewayd daemon for the files that
      have been explicitly flushed to tape.  The PendingMigrationsStore is used to
      hold back FileMigratedNotification messages until the appropriate
      TAPEBRIDGE_FLUSHEDTOTAPE message has been received.  The rtcpd daemon in this
      commit always does at least one synchronised tape-mark per file and sends
      always sends one TAPEBRIDGE_FLUSHEDTOTAPE per file when its client is the
      tapegatewayd daemon.
      9b9847c6
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · c96bfc06
      Steven Murray authored
      I broke the build with my last commit because I have a different version of the BridgeProtocolEnigine class.  Problem now fixed.
      c96bfc06
  7. 21 Jul, 2011 1 commit
  8. 19 Jul, 2011 2 commits
  9. 13 Jul, 2011 1 commit
  10. 12 Jul, 2011 1 commit
  11. 24 Jun, 2011 1 commit
  12. 26 May, 2011 2 commits
  13. 13 May, 2011 1 commit
  14. 29 Mar, 2011 1 commit
  15. 06 Sep, 2010 1 commit
  16. 03 Sep, 2010 1 commit
  17. 23 Mar, 2010 1 commit
  18. 28 Feb, 2010 2 commits
  19. 25 Feb, 2010 2 commits
  20. 24 Feb, 2010 2 commits
  21. 11 Feb, 2010 1 commit
  22. 15 Jan, 2010 2 commits
  23. 11 Jan, 2010 3 commits
  24. 08 Jan, 2010 1 commit
  25. 07 Jan, 2010 2 commits
  26. 06 Jan, 2010 1 commit
    • Steven Murray's avatar
      We now use sstrerror() everywhere we need to convert a system or castor error... · b47c9865
      Steven Murray authored
      We now use sstrerror() everywhere we need to convert a system or castor error number into a string.  Before we were using a mixture of sstrerror, sstrerror_r and strerror_r.  Some of these usages were actually buggy and resulted in garbage strings which could have caused crashes in production (the real reason for this update). To be fair the tapegateway software was already implementing the policy of only using sstrerror
      
      b47c9865
  27. 04 Jan, 2010 3 commits