Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-1052 HDFS scalability with multiple namenodes
  3. HDFS-1655

Federation: DatablockScanner should scan blocks for all the block pools.

    Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Federation Branch
    • Fix Version/s: Federation Branch
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      DataBlockScanner changes are needed to work with federation.
      Goal is to have DataBlockScanner visit one volume at a time, scanning block pools under it one at a time.

      1. HDFS-1655.2.patch
        83 kB
        Jitendra Nath Pandey
      2. HDFS-1655.1.patch
        85 kB
        Jitendra Nath Pandey

        Issue Links

          Activity

          Hide
          Jitendra Nath Pandey added a comment -

          Patch uploaded.

          Show
          Jitendra Nath Pandey added a comment - Patch uploaded.
          Hide
          Jitendra Nath Pandey added a comment -

          Changes in the patch.

          • The block pools are scanned one at a time. Most of the original DataBlockScanner functionality is moved to BlockPoolScanner. The DataBlockScanner runs a scanner thread as before and selects next block pool to scan and invokes BlockPoolScanner to do the scan work.
          • One BlockPoolScanner is instantiated for each block pool which maintains the state of the scan, blockMap and blockInfoSet similar to what DataBlockScanner had before.
          • The current verification log file is created for each block pool and once the block pool scan is complete it is rolled into the previous log file, before processing the next block pool. Therefore, at any instant there should be only one current verification log file.
          • To find the next block pool to scan, the datablock scanner iterates over the set of blockPools. However, if a datanode is restarted it needs to pick the block pool which was being scanned before. Therefore, first it looks for the block pool that contains the current verification log file and that is used as the starting block pool id. If no current files are found it starts with first block-pool.
          Show
          Jitendra Nath Pandey added a comment - Changes in the patch. The block pools are scanned one at a time. Most of the original DataBlockScanner functionality is moved to BlockPoolScanner. The DataBlockScanner runs a scanner thread as before and selects next block pool to scan and invokes BlockPoolScanner to do the scan work. One BlockPoolScanner is instantiated for each block pool which maintains the state of the scan, blockMap and blockInfoSet similar to what DataBlockScanner had before. The current verification log file is created for each block pool and once the block pool scan is complete it is rolled into the previous log file, before processing the next block pool. Therefore, at any instant there should be only one current verification log file. To find the next block pool to scan, the datablock scanner iterates over the set of blockPools. However, if a datanode is restarted it needs to pick the block pool which was being scanned before. Therefore, first it looks for the block pool that contains the current verification log file and that is used as the starting block pool id. If no current files are found it starts with first block-pool.
          Hide
          Jitendra Nath Pandey added a comment -

          Patch rebased against latest state of the branch.

          Show
          Jitendra Nath Pandey added a comment - Patch rebased against latest state of the branch.
          Hide
          Jitendra Nath Pandey added a comment -

          test-patch results.

          [exec] -1 overall.
          [exec]
          [exec] +1 @author. The patch does not contain any @author tags.
          [exec]
          [exec] +1 tests included. The patch appears to include 5 new or modified tests.
          [exec]
          [exec] +1 javadoc. The javadoc tool did not generate any warning messages.
          [exec]
          [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
          [exec]
          [exec] -1 findbugs. The patch appears to introduce 1 new Findbugs warnings.
          [exec]
          [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings.
          [exec]
          [exec] +1 system tests framework. The patch passed system tests framework compile.

          The findbugs warning is for directory scanner, not related to this patch.

          Show
          Jitendra Nath Pandey added a comment - test-patch results. [exec] -1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 5 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] -1 findbugs. The patch appears to introduce 1 new Findbugs warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 system tests framework. The patch passed system tests framework compile. The findbugs warning is for directory scanner, not related to this patch.
          Hide
          Suresh Srinivas added a comment -

          +1 for the change.

          Show
          Suresh Srinivas added a comment - +1 for the change.
          Hide
          Suresh Srinivas added a comment -

          I committed the patch

          Show
          Suresh Srinivas added a comment - I committed the patch
          Hide
          Jitendra Nath Pandey added a comment -

          This patch removes the REMOTE_READ scan type from the DataBlockScanner. Client still verifies the block and namenode is informed if any corruption detected, but the block scanner is not notified to update its scan status for that block. The reasons:
          1. The datanode verification runs in background and should be an independent verification mechanism internal to the datanode.
          2. It is more complicated with federation because block pools are scanned in round robin and a client might verify a block for a block pool scanner which may not be running.
          3. The goal of the optimization was just to skip verification of the block which has been read by the client. This optimization doesn't seem to justify the complexity. Anyway the scanner doesn't verify a block again if it was recently verified.

          Show
          Jitendra Nath Pandey added a comment - This patch removes the REMOTE_READ scan type from the DataBlockScanner. Client still verifies the block and namenode is informed if any corruption detected, but the block scanner is not notified to update its scan status for that block. The reasons: 1. The datanode verification runs in background and should be an independent verification mechanism internal to the datanode. 2. It is more complicated with federation because block pools are scanned in round robin and a client might verify a block for a block pool scanner which may not be running. 3. The goal of the optimization was just to skip verification of the block which has been read by the client. This optimization doesn't seem to justify the complexity. Anyway the scanner doesn't verify a block again if it was recently verified.

            People

            • Assignee:
              Jitendra Nath Pandey
              Reporter:
              Jitendra Nath Pandey
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development