1. 18 Jun, 2013 1 commit
  2. 28 Mar, 2013 1 commit
  3. 11 Jul, 2012 2 commits
  4. 10 Jan, 2012 1 commit
    • Steven Murray's avatar
      bug #90313: RFE: tapebridged should request more files to transfer in bulk · 8aa7b55d
      Steven Murray authored
      The implementation of this RFE is going to take a relatively long period of
      time in that there will be several commits to SVN before it is completed.
      This commit adds some helper classes to the tapebridged source-code base.
      These classes are tested by the unit-tests of the test/unittest directory but
      are not actively used by the tapebridged daemon and so will not effect any
      release that may need to be made of the trunk.
  5. 16 Aug, 2011 1 commit
  6. 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:
      This commit adds the following tapebridge configuration parameter, which today
      is ignored:
      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
      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.
  7. 27 Jul, 2011 1 commit
    • 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.
  8. 20 Jul, 2011 1 commit
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · 541d2336
      Steven Murray authored
      The tapebridged daemon now determines and sends the values of the following
      three CASTOR configuration parameters to the rtcpd daemon:
      Please note that the support for buffered tape-marks over multiple files has
      NOT been implemented.  On top of this, lines 91 to 109 inclusive of the file
      named rtcopy/rtcpd_GetClientInfo.c prevent buffered tape-marks over multiple
      files from even trying to start and these lines create an error message that
      explicitly tells the user that buffered tape-marks over multiple files is not
       91   /* This version of rtcpd does NOT support buffered tape-marks over */
       92   /* multiple files                                                  */
       93   if(*clientIsTapeBridge &&
       94     tapeBridgeClientInfo2MsgBody->useBufferedTapeMarksOverMultipleFiles) {
       95     char dummyErrbuf[32]; /* For fire and forget */
       96     char *const ackMsg =
       97       "Buffered tape-marks over multiple files is not supported";
       99     /* Fire and forget negative acknowledgement to VDQM or tape-bridge */
      100     rtcpd_SendAckToVdqmOrTapeBridge(connSock, netTimeout, msgHdr.reqtype, -1    , 
      101       ackMsg, dummyErrbuf, sizeof(dummyErrbuf));
      103     snprintf(errBuf, errBufLen, "%s()"
      104       ": %s",
      105       __FUNCTION__, ackMsg);
      106     errBuf[errBufLen - 1] = '\0';
      107     serrno = ENOTSUP;
      108     return(-1);
      109   }
  9. 15 Jul, 2011 1 commit
  10. 14 Jul, 2011 1 commit
  11. 13 Jul, 2011 1 commit
  12. 25 Feb, 2010 2 commits
  13. 24 Feb, 2010 2 commits
  14. 28 Jan, 2010 1 commit
  15. 04 Jan, 2010 1 commit
  16. 04 Dec, 2009 1 commit
  17. 12 Oct, 2009 1 commit
  18. 11 Aug, 2009 1 commit
  19. 07 Aug, 2009 2 commits
  20. 04 Aug, 2009 1 commit
    • Steven Murray's avatar
      The DriveAllocationProtocolEngine now sends a tapegateway... · 66e8313d
      Steven Murray authored
      The DriveAllocationProtocolEngine now sends a tapegateway EndNotificationErrorReport if it detects an error.  Tests have shown that RTCPD may not make the initial callback under certain circumstances.  This is an error and should therefore be report to the TapeGateway
  21. 08 Jul, 2009 3 commits
  22. 19 Jun, 2009 1 commit
  23. 11 Jun, 2009 1 commit
  24. 10 Jun, 2009 1 commit
  25. 20 Feb, 2009 2 commits
  26. 15 Feb, 2009 1 commit
  27. 04 Feb, 2009 1 commit
    • Steven Murray's avatar
      Added RTCPD ping. · 6697e2ce
      Steven Murray authored
      Implemented the position, file transfered and end of recall parts of the
      RTCOPY recall protocol.
  28. 30 Jan, 2009 2 commits
  29. 29 Jan, 2009 1 commit
  30. 26 Jan, 2009 1 commit
    • Steven Murray's avatar
      I have moved the code in RtcpdHandlerThread to VdqmRequestHandlerThread and · a4b918f0
      Steven Murray authored
      have removed RtcpdHandlerThread.  The code compiles, but probably does not
      The concurrency and communication model has been decided.  There will be a pool of VDQM threads with one thread per tape drive.  Today there is only one drive
      per tape server at CERN, but we are trying to keep backwards compatibility.
      The existing code we are trying to replace kept open the option of more than
      one drive per tape server.  One VDQM thread will use a select loop to
      communicate with the five or more incomming connections required by RTCPD.  By
      default, RTCPD makes five connections to a client.  The initial connection to
      signal the start of a remote tape copy and to listen for ping and abort
      messages, one connection for the RTCPD tape IO thread, and three connections
      for the default number of three RTCPD disk IO threads.
      The next step is to code the select loop for the five or more connections.
  31. 04 Dec, 2008 1 commit
  32. 03 Dec, 2008 1 commit