1. 16 Sep, 2014 2 commits
  2. 27 Jan, 2014 1 commit
  3. 21 Jan, 2014 1 commit
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · c14886d0
      Steven Murray authored
      This commit removes the retry logic from the rtcpd daemon.  The retry logic has
      to be removed before the replacement of the deltpfil() function can safely
      not call exit(-1) and let the current rtcpd tape session end gracefully.
      c14886d0
  4. 20 Jan, 2014 1 commit
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · f14c920e
      Steven Murray authored
      I have made the save_errno and save_serrno variables of the "horrible macro"
      CHECK_PROC_ERR local.  These two variables should never have been grabbed by
      the macro from the enclosing function tapeIOthread().
      f14c920e
  5. 16 Jan, 2014 1 commit
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · e6bc3702
      Steven Murray authored
      Removed the deltpfil() function that deletes files from the end of a tape in
      order to leave the tape terminated with a correct label structure.  The
      deltpfil() function increases the risk of data loss in a system that uses
      deferred tape flushes.  When appending data to the end of a tape the
      deltpfil() function has been made redundant by the fact that the stageri
      always instructs the tape system to position to the end of the last file
      successfully written to tape as opposed to requesting a tape drive to position
      to end of data.
      e6bc3702
  6. 15 Jan, 2014 1 commit
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · da83dd24
      Steven Murray authored
      Removed the deltpfil() function that deletes files from the end of a tape in
      order to leave the tape terminated with a correct label structure.  The
      deltpfil() function increases the risk of data loss in a system that uses
      deferred tape flushes.  When appending data to the end of a tape the
      deltpfil() function has been made redundant by the fact that the stageri
      always instructs the tape system to position to the end of the last file
      successfully written to tape as opposed to requesting a tape drive to position
      to end of data.
      da83dd24
  7. 01 Dec, 2013 2 commits
  8. 21 Nov, 2013 1 commit
  9. 23 Oct, 2013 1 commit
  10. 21 Oct, 2013 1 commit
  11. 15 Oct, 2013 1 commit
  12. 14 Oct, 2013 1 commit
    • Steven Murray's avatar
      bug #102853: RFE: Remove code implementing unsupported tape label types · 629f6810
      Steven Murray authored
      The refactoring carried out for this RFE has uncovered what maybe a potential
      weakness in the code used to flush data to tape.  This modification is based on
      what we have learnt about the legacy code during its refactoring.  It improves
      the safety of the tape flush logic.  The current code in production has never
      failed, however it is always better to be safer than sorry.
      629f6810
  13. 13 Oct, 2013 1 commit
  14. 03 Oct, 2012 1 commit
  15. 02 Oct, 2012 1 commit
  16. 27 Sep, 2012 1 commit
  17. 22 Aug, 2012 1 commit
  18. 17 Aug, 2012 1 commit
  19. 16 Aug, 2012 1 commit
  20. 14 Aug, 2012 1 commit
  21. 06 Oct, 2011 1 commit
  22. 05 Oct, 2011 1 commit
  23. 22 Sep, 2011 1 commit
  24. 29 Aug, 2011 1 commit
  25. 16 Aug, 2011 1 commit
  26. 09 Aug, 2011 1 commit
  27. 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
  28. 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.
      9b9847c6
  29. 09 Jun, 2011 1 commit
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · 6fe16ff7
      Steven Murray authored
      I have reversed merged the two commits that moved the function named
      rtcpd_SignalFilePositioned out of the source file rtcpd_Tape.c and into its
      own dedicated file.
      
      I have taken this action because I will implement the buffered tape marks over
      multiple files in a different way which does not require cutting rtcpd_Tape.c
      into many separate files.  This change of direction has been made because the
      functions defined in rtcpd_Tape.c share too many global variables and too many
      locally defined macros and datatypes.
      6fe16ff7
  30. 08 Jun, 2011 1 commit
  31. 30 May, 2011 1 commit
  32. 06 Jul, 2010 1 commit
  33. 02 Jul, 2010 1 commit
  34. 28 Jun, 2010 1 commit
    • Sebastien Ponce's avatar
      Cleanup of many useless ifdefs. · 5ffb218b
      Sebastien Ponce authored
      In particular, dropped all code related to unsupported platforms.
      Note that it has been verified that this commit is a noop for the compiled code as the preprocessed code is unchanged (modulo some line numbers).
      5ffb218b
  35. 23 Mar, 2010 1 commit
  36. 14 Aug, 2009 1 commit
  37. 09 Jan, 2009 1 commit
  38. 21 Feb, 2008 1 commit