Skip to Main Content
IBM System Storage Ideas Portal


This portal is to open public enhancement requests against IBM System Storage products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Sep 25, 2017

Improve performance when retrieving partial tapes by using RAO/oRAO on supported tape drives

IBM Enterprise tape drives (TS1140/3592-E07 onwards) supports Recommended Access Order (RAO). LTO-9 drives supports Open Recommended Acces Order (oRAO). This feature allows a tape drive to advise an application on the optimum retrieval order based on the physical placement of data on tape. This is different from the logical ordering done by TSM today as RAO/oRAO caters to the fact that tape recording is in fact multiple tracks done in a serpentine pattern rather than a single track. See [1] for a more detailed explanation of RAO, and [2] for details on oRAO.

We propose to utilize RAO/oRAO on supported tape drives to improve the performance when doing sparse retrievals of tape data. Performance speedups are potentially massive, IBM quotes a 73% access time reduction on a typical sparse retrieve when using oRAO on LTO-9 and the speedup on Enterprise tape drives is even better due to the higher resolution tape directory.


The introduction of even higher capacity tape drives will make RAO/oRAO support mandatory for any tape system to be viable, and Spectrum Protect is currently lagging behind due to lacking this support.


[1] https://www.ibm.com/support/pages/ibm-system-storage-tape-drive-3592-scsi-reference - Ch 4.27 page 87


[2] https://www.ibm.com/support/pages/node/6490249 - Ch 4.6 page 35

Idea priority High
  • Guest
    Reply
    |
    Nov 22, 2022

    Hi!


    In our environment implementing RAO only for the non-query restores (NQR) won't be enough, since NQR isn't a common operation for us. One of our regular activities is retrieving files from tape using dsmc retrieve with a file list, another common activity is space reclamation. Support to perform these operations with good performance is essential for the product to stay relevant for us.


    I acknowledge that there is a challenge in implementing RAO for the dsmc retrieve use case, as the dsmc client-server protocol assumes the client is sorting the files. However, partial RAO support for this use case can likely be implemented with the current protocol, with a few tradeoffs/caveats.


    The basic idea is for the server to set up for a queried restore/retrieve by cache the object list, determine tape volume(s) involved and mount tape(s) and perform RAO, build a RestoreOrder using the RAO information, and finally return the object list to the client. The client will then proceed with sorting the files using the RestoreOrder the server has determined using the RAO-optimized travel plan, and then request the files in an optimized manner.


    A few notes:


    1) The details of the dsmc client-server protocol is a bit unclear from our viewpoint.


    1.1) If the client issues a single query with all the wanted objects the process of building a RAO-optimized RestoreOrder is straight-forward.


    1.2) If instead the client issues multiple queries with one object per query this becomes hard-to-impossible, requiring a revision of the dsmc client-server protocol. Such a revision can range from a minor addition to allow the client to submit a RAO request at the start of processing for each volume, to going all the way and allowing the server to determine the restore order on the fly. The latter could also benefit other operations by co-scheduling access order for multiple sessions/processes (wanting to) access the same volume.

    2) Mounting multiple tapes to perform RAO without actual tape IO is a performance penalty, but if care is taken to not trigger unnecessary tape retention operations the impact should be greatly compensated by the increased efficiency. A tradeoff can be to only do RAO on the tape with the most data in the operation, what's optimal is likely site specific. The best would of course be to only perform RAO in conjunction with a tape mount to perform IO.


  • Guest
    Reply
    |
    Jun 10, 2021

    This request may not be delivered within the release currently under development, but the theme is aligned with the current multi-year strategy. IBM may consider and evaluate any RFE Community feedback for this request through activities such as voting. IBM will update this request in the future.

  • Guest
    Reply
    |
    Jun 29, 2018

    This request may not be delivered within the release currently under development, but the theme is aligned with the current multi-year strategy. IBM may consider and evaluate any RFE Community feedback for this request through activities such as voting. IBM will update this request in the future.

  • Guest
    Reply
    |
    Jun 28, 2018

    We are seeing performance figures that feels less than optimal for sparse retrieves, and we believe that not using Recommended Access Order (RAO) is one of the main contributing factors.

    These numbers are logged by ENDIT, our TSM-dCache integration layer, and are quite representative for the sparse rerievals:

    Retrieve operation from volume HN0424JD successful, 61.19 GiB in 97 files took 3122 seconds, average rate 20.07 MiB/s (0.03 files/s)
    Retrieve operation from volume HN0336JD successful, 72.56 GiB in 41 files took 1293 seconds, average rate 57.46 MiB/s (0.03 files/s)