1. 05 Feb, 2014 3 commits
  2. 04 Feb, 2014 1 commit
  3. 03 Feb, 2014 1 commit
  4. 31 Jan, 2014 1 commit
  5. 28 Jan, 2014 5 commits
  6. 27 Jan, 2014 2 commits
  7. 24 Jan, 2014 2 commits
  8. 22 Jan, 2014 7 commits
  9. 21 Jan, 2014 4 commits
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · ea2b47cf
      Steven Murray authored
      With this commit the logic replacing the deltpfile() function now only logs an
      appropriate message and then allows the rtcp child process to end the current
      tape session gracefully.
    • 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.
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · 234d7e4f
      Steven Murray authored
      Unfortunately I had to lean on TeamCity and break the build in order to
      discover my last commit did not include a vital modification to the
      LogHelper class of the tapebridged daemon.
    • Steven Murray's avatar
      bug #103642: Remove the deltpfil() function · 282e075c
      Steven Murray authored
      The current removal of the deltpfil() function is not satificatory.  The current
      solution effectively replaces the deltpfil() function with a log message and a
      call to exit(-1).  The call to exit(-1) prohibits the propagation of a TAPE
      OVERFLOW error to the tapegatewayd daemon in the event that a tape server
      writes past the physical end of a tape.  This side effect means that tapes are
      mounted in a loop once they become physically FULL because the vmgrd daemon is
      never notified that they are FULL.  The mount loop is actually finite because
      depending on the length of the last file(s) be written to tape the TAPE OVERFLOW
      is detected by different parts of the tape server code and the parts that would
      not have called the deltpfil() function are able to propagate the TAPE OVERFLOW
      error to the tapegewayd daemon which in turn is able to notify the vmgrd daemon
      that the tape in question is now FULL.
      The new idea that is yet to be implemented, is to simply log a message instead
      of calling deltpfil() and then let the rtcpd tape session end gracefully.  This
      graceful end of tape session must not run the risk of trying to write to tape
      again in some form of retiry logic.  I am therefore currently trying to remove
      all retry related code.  One such collection of related code is the now
      obsolete abort protocol, where a client of rtcpd sends it an RTCP_ABORT_REQ
      message.  This commit removes the defunct marshalling code for RTCP_ABORT_REQ
      messages from the tapebridged daemon.
  10. 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().
  11. 16 Jan, 2014 3 commits
  12. 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.
  13. 14 Jan, 2014 1 commit
    • Giuseppe Lo Presti's avatar
      Fixed bug #103625: Incorrect logic to clean up repack requests may lead · 492fe696
      Giuseppe Lo Presti authored
      submitted requests to disappear.
      The logic to clean up old requests has been changed: failed requests
      are kept respecting the timeout in CastorConfig, successful requests
      may be dropped earlier (as in the past) to keep the SubRequest table from
      growing too much.
      In consequence, the repack reporting has been adapted: the 'migrated'
      count is now computed by difference with the other counters, while the
      'failed' count can be trusted because of the above.
  14. 07 Jan, 2014 1 commit
  15. 19 Dec, 2013 1 commit
  16. 18 Dec, 2013 5 commits
  17. 17 Dec, 2013 1 commit