1. 15 Jun, 2021 1 commit
  2. 02 Jun, 2021 1 commit
  3. 14 Jan, 2021 1 commit
  4. 23 Jul, 2019 1 commit
  5. 19 Jul, 2019 1 commit
  6. 12 Dec, 2018 1 commit
  7. 03 Apr, 2017 1 commit
    • Eric Cano's avatar
      cta/CTA#46: Adding garbage collection for object store structures: · cfe8f58b
      Eric Cano authored
      Created a garbage collector subprocess for the drive daemon.
      Created a AgentHeartbeat thread and added it to frontend, drive subprocess and GC subprocess.
      Fixed logs and drive subprocess.
      Renamed common/threading/Threading.[hc]pp to Thread.[hc]pp as there is only one class left in this file.
  8. 11 Oct, 2016 2 commits
    • Steven Murray's avatar
      Deleted mediachanger dir from castor dir · b38715e6
      Steven Murray authored
    • Victor Kotlyar's avatar
      Ported commits from castor/master for Encryption: · 1a3812e0
      Victor Kotlyar authored
        CASTOR-5350: Introduce encryption SCSI commands in tape drive
        Implementation of two methods:
          * setEncryptionKey(key): Sets encryption params to drive.
          * clearEncryptionKey: Clears encryption params from drive.
        Added support for an interface script that will setup drive
        encryption per tape
        Migrate TapeWriteSingleThread::TapeCleaning::~TapeCleaning() body to
        CASTOR-5350: Refactor support for only external key management script
        Merge branch 'encryption_backend' into 'master'
        CASTOR-5350: Encryption backend
        ## Description
          The aim of this merge request is to incorporate encryption support
          into CASTOR.
          The proposed changes are to be used in conjunction with the
          The **aim** is to enable encryption in specific tape pools of
        ## Changes
          * Introduce encryption SCSI backend to DriveGeneric.
          * Introduce encryption control wrapper
          * (`castor/tape/tapeserver/daemon/EncryptionControl`) for
          * abstracting the two sub-components of:
            * Calling the `ExternalEncryptionKeyScript`,
            * Calling the equivalent DriveGeneric function for
            * passing/clearing the encryption parameters to/from the drive.
          * Add new configuration option in `castor.conf` for the external key
          * management script.
          * Create a Subprocess wrapper for executing external commands as
          * CASTOR children (`castor/server/Subprocess.{h,c}pp`).
          * Incorporate encryption handling in the:
            * DataTransferSession
            * LabelSession
            * CleanerSession
          * Add encryption control timer in the task Watchdog.
        See merge request !1
        Clear encryption key only when encryption enabled
        Changes include:
          - Making EncryptionControl stateful
          - Calling clearEncryptionKey on the drive only when encryption is
        Also includes a minor duplicate code fix on DriveGeneric.
        Merge branch 'encryption_changes' into 'master'
        Clear encryption key only when encryption enabled
        ## Description
          Changes include:
          - Making EncryptionControl stateful
          - Calling `clearEncryptionKey()` on the drive only when encryption
            is on.
          Also includes a minor duplicate code fix on **DriveGeneric.cpp**.
        See merge request !2
        Check if the drive has encryption capability enabled:
          * Add isEncryptionCapEnabled() vendor-specific function
          * Check isEncryptionCapEnabled() before passing encryption params
          * Check isEncryptionCapEnabled() before clearing encryption params
          * Clear encryption key before unencrypted I/O
        Merge branch 'encryption_capability_enabled' into 'master'
        Drive encryption capabilities inclusion
        ## Description
          The aim of this merge request is to address issues related to
          encryption on drive without the encryption capability enabled.
          More specifically:
            * It introduces a vendor-specific way of identifying if the drive
            * has encryption capability enabled
            * **IBM**: Through the SPIN index SCSI page
            * **Oracle**: Through the general INQUIRY SCSI page
            * If the data to be written are to be encrypted, an additional check
            * of the encryption capability of the drive is made. In case of
            * encrypted data, but no encryption capability, the session fails.
            In essence, all encryption related operations are made modulo the
          encryption capability of the drive.
            Last, in case of unencrypted I/O, we clear the keys of the drive (if
          encryption capable) to avoid encrypted data with previous keys on
          CASTOR's system failure.
        ## Testing
          Before the merge request's submission, the following tests were
            On drives with **encryption capability enabled**:
              * Label session
              * Label with previously set encryption key
              * Write without encryption
              * Read without encryption
              * Write with encryption
              * Read with encryption
              * Write with previously set encryption key
              * Read with previously set encryption key
            On drive with **encryption cabability disabled**:
              * Label session
              * Write without encryption
              * Read without encryption
              * Write with encryption - session **should** fail
              * Read with encryption - session **should** fail
          See merge request !3
        Secure session against invalid encryption script output
        Changes in encryption workflow
          - VMGR tag is updated only on write operations
          - Empty key signifies no encryption
        Minor encryption log enhancements
          * Error line in Read/Write session with ErrorMesage key
          * Fix for delimiter in the end of arguments in argsToString()
        Merging in improvements on tape encryption support.
        Removed nullptr which is not supported in SLC6's gcc.
        Added automatic deletion of json objects in
        Fix log typo
  9. 06 Oct, 2016 2 commits
    • Eric Cano's avatar
      Implemented drive status support in drive register structure and code. · 56c4c332
      Eric Cano authored
      Added drive status reporting in scheduler
      Added drive status reporting in OStoreDB
      Added support for drive status listing in the front end
      Removed virtual functions from the Scheduler, which is never overloaded.
      Added DesiredDriveState structure to drive state.
      Removed usage of duplicate MountType, DriveStatus and DriveState structures.
      Created DriveInfo structure to allow recreation of drive register entry in all
      reporting situation (potentially with partial/assumed info).
    • Victor Kotlyar's avatar
      Ported commit 2a14c5d7ef7bb395a37454789abcbfd7266edcc2 from castor/master · a4776842
      Victor Kotlyar authored
      CASTOR-4982: tapeserverd should tolerate some non-fatal tape alerts
      before writing
      Add logic to the TapeWriteSingleThread to skip not-fatal tape
      alerts before writing to the tape. Only "Lost statistics"
      tapeAlertLostStatistics 0x32 tolerated as non-fatal.
  10. 30 Sep, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master for general,drive,volume SCSI statistics: · e8b4ec34
      Victor Kotlyar authored
        CASTOR-5322 RFE: Enhance tapeserverd logs with SCSI tape drive
        Fix for mhtvl scsi log sense exceptions
        CASTOR-5329 Enhance tape statistics
        CASTOR-5332 RFE: Reduce log level to INFO with MHVTL - SCSI Statistics
          could not be acquired from drive
        Move volume SCSI statistics inside the dtor of TapeCleaningMove volume
          SCSI statistics inside the dtor of TapeCleaning
        ## Description
        When first introduced volume SCSI Statistics (at the moment
        IBM-specific), we explicitly put the function after the unmount of the
        tape was done due to an invalid file descriptor error occurring during
        the SCSI query.
        This bug no longer occurs for IBM drives.
        This may be attributed to the update of firmware of the IBM drives
        Apart from the change of the position of the changes, there is no
        alteration in terms of the metrics reported from the drive to the logs.
        ## Testing
        The tests the new code has been through are:
          * Write/Read file on IBM lib0 drive *(older one)*
          * Write/Read file on IBM lib4 drive *(newer one)*
          * Write/Read file on Oracle T10k drive
  11. 28 Sep, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits 006b997699682938ec8a6af9a41498c8194cf451 · 6690990a
      Victor Kotlyar authored
      d1689f3b72329bcc6c342666095567f547f1678f from castor/master
      CASTOR-4909: tapeserverd tries to unmount the tape when the mount
      Made the ignoring of exception throw by DriveGeneric::waitUntilReady
      more specific: we now ignore timeouts, but not the other exceptions.
  12. 09 Sep, 2016 1 commit
  13. 06 Sep, 2016 1 commit
  14. 05 Sep, 2016 1 commit
  15. 01 Sep, 2016 1 commit
  16. 29 Aug, 2016 2 commits
    • Eric Cano's avatar
      Simplified the interface of the TapedProxy and TapeServerReporter. · 2bf36ce4
      Eric Cano authored
      The TapeServerReporter, which is the main interface for the tape thread and tasks,
      now has a simple reportState() function instead of mnay ad-hoc ones. The only ones
      remaining are reportTapeUnmountedForRetrieve() and reportDiskCompleteForRetrieve()
      as they allow managing the special case of retrieve where the session can from
      Running to either ShutingDown or DrainingToDisk depending on which order the
      threads complete.
      The actual calls to send messages to taped are now 3: reportState,
      addLog, removeLog.
    • Steven Murray's avatar
  17. 24 Feb, 2016 2 commits
  18. 29 Jan, 2016 1 commit
  19. 08 Dec, 2015 1 commit
  20. 05 Dec, 2015 1 commit
  21. 14 Aug, 2015 1 commit
  22. 07 Aug, 2015 1 commit
  23. 24 Jul, 2015 1 commit
  24. 16 Jul, 2015 2 commits
  25. 15 Jul, 2015 2 commits
  26. 26 Mar, 2015 1 commit
  27. 03 Mar, 2015 1 commit
  28. 18 Feb, 2015 1 commit
  29. 03 Dec, 2014 1 commit
  30. 02 Dec, 2014 1 commit
  31. 27 Nov, 2014 1 commit
  32. 20 Nov, 2014 1 commit
  33. 19 Nov, 2014 1 commit
    • Eric Cano's avatar
      CASTOR-4832: tapeserverd should report error counts in the end of session statistics · 08e744a3
      Eric Cano authored
      Propagated references to the watchdog to disk and tape threads and tasks.
      Added a maps for storing the count of all errors that occured during the session.
      Added propagation of the counts to the initial process.
      Added error reporting in disk and tapes threads and tasks by using a string marker
      allowing to know which part went wrong in high level exception. Exceptions then
      bumps up the count in the watchdog (synchronously), and the watchdog sends the
      new count to the initial thread later (in the watchdog's thread).
      Plus some missing logs fixed when an exception is thrown in a disk write task.
      Added interface to reference the recall watchdog to the recall disk thread pool.
      Next: Do same for migration. Actually store the reference. Add new error map storing in watchdog. Add error reporting in tape and disk threads.
      WIP: Added missing file ID for disk write thread. Added missing error log when an exception is thrown in a disk write task.
      WIP: switching to CASTOR-4839 tapeserverd: task injector should decide on closing the session earlier
      WIP. Next: log unmount errors (in the RAII)
      Finished error counting in data threads.
  34. 28 Oct, 2014 1 commit
    • Eric Cano's avatar
      CASTOR-4743: tapeserverd logs fixes Naan + unclear message · 302992f6
      Eric Cano authored
      The offending message has been changed in a previous case: CASTOR-4749
      Reviewed all bandwidth calculations to homogenize the statistics printing.
      Fixed a bug where the total time for a session was not properly retrieved before logging, leading to NaN printouts.