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

imperative recovery

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: Lustre 2.0.0, Lustre 1.8.6
    • Fix Version/s: Lustre 2.2.0
    • Labels:
      None
    • Bugzilla ID:
      18,767
    • Rank (Obsolete):
      10457

      Description

      Imperative recovery means the clients are notified explicitly when and where a failed target has
      restarted. Ideally the notification should occur after the target has mounted and is waiting for
      connections. A fully automated version of this will require a new mechanism for distributing node
      health information efficiently. A simple, initial version can be done as a /proc file for each
      import that can be used to initiate recovery.

        Attachments

          Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-573 conf-sanity test_22: @@@@@@ FAIL: test_22 failed with 41

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          New Feature - A new feature of the product, which has yet to be developed. LU-10360 use Imperative Recovery logs for client->MDT/OST connections

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. LU-13306 allow clients to accept mgs_nidtbl_entry with IPv6 NIDs

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. LU-569 make lu_object cache size adjustable

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

            Activity

              People

              • Assignee:
                jay Jinshan Xiong (Inactive)
                Reporter:
                jay Jinshan Xiong (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: