Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Critical
    • Resolution: Duplicate
    • Affects Version/s: HA branch (HDFS-1623)
    • Fix Version/s: None
    • Component/s: ha
    • Labels:
      None

      Description

      As described in the comments of HDFS-1975:

      1) Active NN receives setReplication to drop some file's replication from 3 to 1
      2) It writes OP_SET_REPLICATION to its log, invalidates two replicas, and returns
      3) The DNs report BLOCK_INVALIDATED back to both the ActiveNN and SBNN.
      4) The SBNN hasn't received the OP_SET_REPLICATION yet, so it marks the block as under-replicated.

      In the case of raising replication (eg from 1 to 3) we get the opposite problem: the SBNN marks the block as over-replicated and adds two of the replicas to its invalidation list.

      Generation stamps don't help here, because changing replication level of a block doesn't change its gen-stamp (and it shouldn't). One possible answer is that we need to modify FSNamesystem.isPopulatingReplQueues to return false on the standby, and then when it switches from standby to active, initialize the replication queues only after reading the latest edits... I think that will solve the SET_REPLICATION issue, but not certain if it will solve all the issues in this general class.

        Issue Links

          Activity

          Hide
          tlipcon Todd Lipcon added a comment -

          This work got incorporated into HDFS-1972

          Show
          tlipcon Todd Lipcon added a comment - This work got incorporated into HDFS-1972

            People

            • Assignee:
              tlipcon Todd Lipcon
              Reporter:
              tlipcon Todd Lipcon
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development