Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-10285 Storage Policy Satisfier in HDFS
  3. HDFS-13165

[SPS]: Collects successfully moved block details via IBR

    XMLWordPrintableJSON

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: HDFS-10285, 3.2.0
    • Component/s: None
    • Labels:
      None

      Description

      This task to make use of the existing IBR to get moved block details and remove unwanted future tracking logic exists in BlockStorageMovementTracker code, this is no more needed as the file level tracking maintained at NN itself.

      Following comments taken from HDFS-10285, here

      Comment-3)

      BPServiceActor
      Is it actually sending back the moved blocks? Aren’t IBRs sufficient?

      Comment-21)

      BlockStorageMovementTracker
      Many data structures are riddled with non-threadsafe race conditions and risk of CMEs.

      Ex. The moverTaskFutures map. Adding new blocks and/or adding to a block's list of futures is synchronized. However the run loop does an unsynchronized block get, unsynchronized future remove, unsynchronized isEmpty, possibly another unsynchronized get, only then does it do a synchronized remove of the block. The whole chunk of code should be synchronized.

      Is the problematic moverTaskFutures even needed? It's aggregating futures per-block for seemingly no reason. Why track all the futures at all instead of just relying on the completion service? As best I can tell:

      It's only used to determine if a future from the completion service should be ignored during shutdown. Shutdown sets the running boolean to false and clears the entire datastructure so why not use the running boolean like a check just a little further down?
      As synchronization to sleep up to 2 seconds before performing a blocking moverCompletionService.take, but only when it thinks there are no active futures. I'll ignore the missed notify race that the bounded wait masks, but the real question is why not just do the blocking take?
      Why all the complexity? Am I missing something?

      BlocksMovementsStatusHandler
      Suffers same type of thread safety issues as StoragePolicySatisfyWorker. Ex. blockIdVsMovementStatus is inconsistent synchronized. Does synchronize to return an unmodifiable list which sadly does nothing to protect the caller from CME.

      handle is iterating over a non-thread safe list.

        Attachments

        1. HDFS-13165-HDFS-10285-10.patch
          141 kB
          Rakesh Radhakrishnan
        2. HDFS-13165-HDFS-10285-09.patch
          141 kB
          Rakesh Radhakrishnan
        3. HDFS-13165-HDFS-10285-08.patch
          194 kB
          Rakesh Radhakrishnan
        4. HDFS-13165-HDFS-10285-07.patch
          172 kB
          Rakesh Radhakrishnan
        5. HDFS-13165-HDFS-10285-06.patch
          155 kB
          Rakesh Radhakrishnan
        6. HDFS-13165-HDFS-10285-05.patch
          153 kB
          Rakesh Radhakrishnan
        7. HDFS-13165-HDFS-10285-04.patch
          155 kB
          Rakesh Radhakrishnan
        8. HDFS-13165-HDFS-10285-03.patch
          120 kB
          Rakesh Radhakrishnan
        9. HDFS-13165-HDFS-10285-02.patch
          121 kB
          Rakesh Radhakrishnan
        10. HDFS-13165-HDFS-10285-01.patch
          114 kB
          Rakesh Radhakrishnan
        11. HDFS-13165-HDFS-10285-00.patch
          31 kB
          Rakesh Radhakrishnan

          Activity

            People

            • Assignee:
              rakeshr Rakesh Radhakrishnan
              Reporter:
              rakeshr Rakesh Radhakrishnan
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: