1. 15 Jun, 2021 1 commit
  2. 02 Jun, 2021 1 commit
  3. 13 Oct, 2020 1 commit
  4. 25 Sep, 2020 5 commits
  5. 01 Apr, 2020 1 commit
  6. 06 Dec, 2017 1 commit
  7. 27 Sep, 2017 1 commit
  8. 29 Aug, 2017 2 commits
  9. 28 Aug, 2017 1 commit
  10. 26 May, 2017 3 commits
    • Cristina Moraru's avatar
      0ad2455c
    • Cristina Moraru's avatar
      After feedback · d5a8098c
      Cristina Moraru authored
      
      Signed-off-by: default avatarCristina Moraru <cristina-gabriela.moraru@cern.ch>
      d5a8098c
    • Cristina Moraru's avatar
      Implement RAO at the drive level #57 · c8b74a53
      Cristina Moraru authored
      
      
      This commit adds the feature of querying the drive for the
      Recommended Access Order (RAO) of a series of files and adds
      a test file for this feature.
      
      Changes of this commit:
        *  Extend the DriveInterface with a virtual method queryRAO
      which takes as parameter the name of the file containing a set
      of files for which the RAO is requested. The line format of this
      file is the following:
      
      FILE_ID:BLOCK_START:BLOCK_END
      
        *  Extend DriveGeneric class with the implementation of the
      method queryRAO, along with a few other auxiliary methods; some
      key auxiliary methods are getLimitUDS, generateRAO, receiveRAO
      
        *  Add method queryRAO in object FakeDrive returning Exception:
      Not Implemented
      
        *  Add auxiliary constants and structures in a new 'RAO' namespace
      
        *  Add test file: BasicReadWriteTest.cpp which can perform 3 tests
      according to the setting of variable 'test'
      	1. BLOCK_TEST - basic read / write of blocks
      	2. FILE_TEST - writes a series of CASTOR files and reads
      a random one
      	3. RAO_TEST - performs a RAO query for a series of files
      given in the filename specified in argv[1]. The file format should
      respect the above mentioned order.
      Signed-off-by: default avatarCristina Moraru <cristina-gabriela.moraru@cern.ch>
      c8b74a53
  11. 20 Oct, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master: · a6c49d63
      Victor Kotlyar authored
      1d92302d5304266ee14a86b8d9fcbd671b567e5c
        Fix for drive::xx::clearCompressionStats
          - For DriveT10000, DriveMHVTL: stateful accumulator
          - For DriveIBM3592, DriveLTO: log select on specific log page
      
      e6780a8f0a5ed6366ae750eaecc189ac7d0d07fe
        Fix overflowing mountTotal{Read,Write}BytesProcessed by bumping up
        to 64-bit container
      
      12c31edf5193dae90ef65eaa6c3d0eb81a7c6927
        Refactor fix for drive::xx::clearCompressionStats
      
      f626a773aae60b36146d3170e4eb2ef5fd13db35
        Merge branch 'fix_clear_compression_stats' into 'master'
        Fix clear compression stats
      
        ## Description
          The aim of this merge request is to fix the
          `drive::clearCompressionStats()` method which deleted all log metrics
          with log select on page 0x00 (aka reset all metrics).
          The following changes are introduced:
            * For **IBM and LTO drives**: We are selectively clearing only the
            * compression statistics (pages 0x38, 0x32 equivalently)
            * For **Oracle and MHVTL drives**: Wa are making compression
            * statistics stateful, by accumulating values and subtracting on
            * each flush
          Moreover, we are piggybacking a fix for overflowing
          mountTotal{Read,Write}BytesProcessed
          (drive::xx::getTape{Read,Write}Errors) by bumping up the container map
          in 64-bit value
      
        ## Testing
          The results of the changes were tested against IBM and Oracle
          drives.
          More specifically, we attempted to write 40 randomly generated files
          of 2GB in size with the previous CASTOR version (2.1.16-9), extracted
          the compression metrics and compared
      
        ### IBM
          **before:**
            ```
            Oct  6 12:23:09 tpsrv240 tapeserverd[14257]: LVL="Info" TID="14268"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            Oct  6 12:24:53 tpsrv240 tapeserverd[14257]: LVL="Info" TID="14268"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            Oct  6 12:25:45 tpsrv240 tapeserverd[14257]: LVL="Info" TID="14268"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            ```
          **after: **
            ```
            Oct  6 12:34:28 tpsrv240 tapeserverd[14836]: LVL="Info" TID="14847"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            Oct  6 12:36:12 tpsrv240 tapeserverd[14836]: LVL="Info" TID="14847"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            Oct  6 12:37:04 tpsrv240 tapeserverd[14836]: LVL="Info" TID="14847"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tps
            ```
      
        ### Oracle
          **before:**
            ```
            Oct  6 12:21:44 tpsrv614 tapeserverd[3062]: LVL="Info" TID="3073"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            Oct  6 12:24:02 tpsrv614 tapeserverd[3062]: LVL="Info" TID="3073"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            Oct  6 12:25:12 tpsrv614 tapeserverd[3062]: LVL="Info" TID="3073"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            ```
          **after:**
            ```
            Oct  6 12:34:58 tpsrv614 tapeserverd[3691]: LVL="Info" TID="3702"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            Oct  6 12:37:16 tpsrv614 tapeserverd[3691]: LVL="Info" TID="3702"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            Oct  6 12:38:26 tpsrv614 tapeserverd[3691]: LVL="Info" TID="3702"
            MSG="Reported to the client that a batch of file was written on tape"
            thread="ReportPacker" clientHost="tpsrv
            ```
      See merge request !11
      a6c49d63
  12. 11 Oct, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master for Encryption: · 1a3812e0
      Victor Kotlyar authored
      6b6374d6c2e209c98c0d4d7aa665e1df83d71aaa
        CASTOR-5350: Introduce encryption SCSI commands in tape drive
        backend
      
        Implementation of two methods:
          * setEncryptionKey(key): Sets encryption params to drive.
          * clearEncryptionKey: Clears encryption params from drive.
      
      3cf91d48f5c7b0cb563c3037aee69ec769f5ab94
        Added support for an interface script that will setup drive
        encryption per tape
      
      e9ca601687508de20fab7154e63bb0dbd1b25a8a
        Migrate TapeWriteSingleThread::TapeCleaning::~TapeCleaning() body to
        .cpp
      
      266b02d8175b5cfc0b688135cbdc335e93060b
        CASTOR-5350: Refactor support for only external key management script
      
      789b26a0bc69053ff1ab792a02676a7753f093ed
        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
          operators'
          [ExternalEncryptionKeyScript](https://gitlab.cern.ch/slaskari/castor-get-encryption-key).
      
          The **aim** is to enable encryption in specific tape pools of
          CASTOR.
        ## 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
      
      fa550707c42d80466bbd448e355aaf9be5ea8e04
        Clear encryption key only when encryption enabled
        Changes include:
          - Making EncryptionControl stateful
          - Calling clearEncryptionKey on the drive only when encryption is
            on.
        Also includes a minor duplicate code fix on DriveGeneric.
      cf4eb9f3ae36c9cfc9c40349d69ab6642020e81e
        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
      
      40366d963ee33ca081df6c991189b21369e461fd
        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
      
      4ccc661d01eccfc3fdfb9ee2578d15a147a0c55a
        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
          passed:
            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
      
      55b85a2cb4681d697565116c00ff98c6becea4fb
        Secure session against invalid encryption script output
      
      3a54875c680fe6c1c9d5cf25cf98d2780196e0d1
        Changes in encryption workflow
          - VMGR tag is updated only on write operations
          - Empty key signifies no encryption
      
      f5408cf0ccbae9a4ab94a533f3b6d7be323f72fb
        Minor encryption log enhancements
          * Error line in Read/Write session with ErrorMesage key
          * Fix for delimiter in the end of arguments in argsToString()
      2e7204fb0dd24b472a959fa5e13320c34df4f017
        Merging in improvements on tape encryption support.
      
      92533a1746d0744ee528781558a720c63ca3c4d1
        Removed nullptr which is not supported in SLC6's gcc.
        Added automatic deletion of json objects in
        EncryptionControl::parse_json_script_output.
      
      fca3bb9e7fce364b429fc0b5c036fb752fd67ff1
        Fix log typo
      1a3812e0
  13. 07 Oct, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master: · fc0de7b6
      Victor Kotlyar authored
      3a67b08bd5b0e0cf4ef03de8185630fb0bcc5e80
        CASTOR-5275 RFE: Log the tapeserverd tape-file descriptor if it
        becomes bad whilst waiting for a tape drive to become ready
      
        Fixed.
      
      b5d562503b6f954cfc6be09ef742474c685e6d60
        CASTOR-5275 RFE: Log the tapeserverd tape-file descriptor if it becomes
        bad whilst waiting for a tape drive to become ready
      
        Differentiated the log messages, and added the file descriptor
        logging in  all instances of the Could not read drive status errors.
      fc0de7b6
  14. 06 Oct, 2016 1 commit
  15. 05 Oct, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master: · 9dfbe96d
      Victor Kotlyar authored
      83ab8201100d1bcdd5c6d056fd5a395c24bcb885
        Get detailed Firmware Version
          - Differentiate SCSI Inquiry for Oracle to get firmware version
            minor version
          - Change getDriveFirmwareVersion() to get firmware version from SCSI
            backend
      
      6481bcabc4907c8a1813253fe9a2d40cd67d07fe
        Provide DriveGeneric inquiry implementation for DriveMHVTL
      
      2033932f133b9eb7469190972a4f228dd8b16396
        Move Oracle inquiry structure handling inside
        DriveT10000::getDeviceInfo()
      
      a8be8c16a4e3af2f952676f1138213d7e5584705
        Merge branch 'tape-firmware' into 'master'
          Get detailed Firmware Version
          ## Description
            - Differentiate SCSI Inquiry for Oracle to get firmware version
              minor version
            - Change getDriveFirmwareVersion() to get firmware version from SCSI
              backend
          ## Change in logs
            Old version:
              firmwareVersion="468E" # IBM
              firmwareVersion="4.11" # Oracle
            New version:
              firmwareVersion="468E" # IBM
              firmwareVersion="4.11.111" # Oracle
      9dfbe96d
  16. 03 Oct, 2016 2 commits
    • Victor Kotlyar's avatar
    • Victor Kotlyar's avatar
      Ported commits from castor/master: · 3c60ee4b
      Victor Kotlyar authored
      d28aa41f02ffe8e944e3981d51a73a261613affa
        Volume SCSI metrics implementation for Oracle T10K
      
        After new update of firmware (4.11), Oracle has introduced an
        implementation for SCSI page 0x17. Integrating metrics to CASTOR.
      
      d140f448f8913f0573940a39d391b384d5296dc7
        Add comment for Oracle specific implementation on Volume SCSI page 0x17
      
      1f7c854f222633ea0d7e2c717dc38e276c899a13
        Volume SCSI metrics implementation for Oracle T10K
      
        ## Description
          After new update of firmware (4.11), Oracle has introduced an implementation
          for SCSI page 0x17 (Volume statistics). Integrating metrics to CASTOR.
        ## Metrics
          * validity
          * lifetimeVolumeMounts
          * lifetimeVolumeRecoveredWriteErrors
          * lifetimeVolumeRecoveredReadErrors
          * volumeManufacturingDate
      
      adb79718f17b668d9ac5d19b26708a1b9975150e
      b51dfaafc546047d580d7d609621f88bc9d40f4b
        Add unimplemented MHVTL Volume Statistics SCSI page
      
        Page 0x17 is not implemented in MHVTL.
        As it inherits from DriveT10000D, it should be overridden in order
        to return empty map of metrics values.
      
      8a810d013ace455722b79125586e9551c73716d8
        Add unimplemented MHVTL Volume Statistics SCSI page
      
        ## Description
          Page 0x17 is not implemented in MHVTL.
          As it inherits from DriveT10000D, it should be overridden in order
          to return empty map of metrics values.
      3c60ee4b
  17. 30 Sep, 2016 1 commit
    • Victor Kotlyar's avatar
      Ported commits from castor/master for general,drive,volume SCSI statistics: · e8b4ec34
      Victor Kotlyar authored
      fa889fed2541e22179b5e035d863f87e7be18fb9
        CASTOR-5322 RFE: Enhance tapeserverd logs with SCSI tape drive
          statistics
      
      b13f495e4ee229b2469f9470a2ffa6b4003a29ec
        Fix for mhtvl scsi log sense exceptions
      
      ad71058fbcb6de85e0440797d7ffa5358e26bf89
        CASTOR-5329 Enhance tape statistics
      
      806e48f4285122d8ab9f118364a15e740518028f
        CASTOR-5332 RFE: Reduce log level to INFO with MHVTL - SCSI Statistics
          could not be acquired from drive
      
      79c5a4c2c36b7acc5b10505ca1694fd521fc6832
      c7f6d4d7aaa564b37c2b36c3110dfe2fc96ec970
        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
      e8b4ec34
  18. 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
      failed...
      
      Made the ignoring of exception throw by DriveGeneric::waitUntilReady
      more specific: we now ignore timeouts, but not the other exceptions.
      6690990a
  19. 27 Sep, 2016 1 commit
  20. 06 Sep, 2016 2 commits
  21. 31 Aug, 2016 1 commit
  22. 30 Aug, 2016 1 commit
  23. 29 Aug, 2016 1 commit
  24. 25 Feb, 2016 3 commits
  25. 24 Feb, 2016 5 commits