Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-9961

FLR2: Relocating objects to a new OST

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: Lustre 2.7.0, Lustre 2.9.0
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
    • Rank (Obsolete):
      9223372036854775807

      Description

      This ticket is twofold: 1) how do we efficiently migrate data off a set of OSTs with current or quick-hack tools? 2) what features and tools can be developed in the future to improve usability?

      We have an older file system from which we are trying to remove a set of OSTs on a single server. To do this, we need to drain data off of the targets and onto the rest of the same file system. Initially we used the "lctl deactivate" method, but then switched to "lctl set_param osp.<OST>.max_create_count=0" due to the issues discussed in LU-4825 (and others). Unfortunately, users tend to keep data on this file system for a long time, so normal turnover is not significantly decreasing the usage of the OSTs.

      Our understanding is that (with current versions of Lustre) to move objects off of the desired targets all parts of the file would have to be read and rewritten by a client, even if only one of many stripes is on the target. This is unacceptably inefficient, as the existence of files striped with a count of more than one results in a huge increase in the total data to be rewritten. In our case it would be well over half of the data on the file system. We are able to gather file size and stripe data (and the lists of files) using e2scan, Lester, and wrapper scripts.

      1) What tools and methods are available to drain the OSTs more efficiently? Preferably it would involve a background process to copy just the individual objects on the OSS to be drained. And then we are open to taking a moderate downtime to just update the MDT to change layout info to point to the new object locations.

      2) Can this use case be supported in the future by a tool like lfs_migrate, with options or auto-detection, to only move the parts of the file that need to be moved to satisfy the new target requirements? As an interim step, a server-side administrator command to initiate the object relocation would be fine.

      Thanks!

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              pjones Peter Jones
              Reporter:
              ndauchy Nathan Dauchy (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated: