FAQ
Block allocation method does not check pendingCreates for duplicate block ids
-----------------------------------------------------------------------------

Key: HADOOP-1444
URL: https://issues.apache.org/jira/browse/HADOOP-1444
Project: Hadoop
Issue Type: Bug
Components: dfs
Reporter: dhruba borthakur


The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.

The above check for detecting duplicate blockid should check pendingCreateBlocks as well.

A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.



--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Search Discussions

  • dhruba borthakur (JIRA) at Jun 2, 2007 at 5:40 am
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur reassigned HADOOP-1444:
    ----------------------------------------

    Assignee: dhruba borthakur
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur

    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 5, 2007 at 6:37 am
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Attachment: duplicateBlockId.patch

    This patch does two things:

    1. Moves all the pendingCreates logic into PendingCreates.java. This data structures encapsulates pendingCreates and pendingCreateBlocks from FSNamesystem.

    2. The block allocation routine FSNamesystem.allocate() verifies that the new blockid that is generated does not already exists in the blocksMap as well as pendingCreates.

    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Konstantin Shvachko (JIRA) at Jun 7, 2007 at 8:30 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502506 ]

    Konstantin Shvachko commented on HADOOP-1444:
    ---------------------------------------------

    PendingCreates:
    - Redundant import:
    import org.apache.hadoop.util.*;
    - Redundant member:
    private Log LOG = null;
    - Member pendingCreates lost the comment explaining the meaning and the mapping type.

    FSNamesystem:
    - Member pendingCreates comment should be updated.
    - FSNamesystem.abandonBlock()
    -- First stateChangeLog() report is redundant because it is already reported by the NameNode.abandonBlock()
    -- It would be better to report the result of block removal whether it was successful or not,
    rather than reporting just the success and keeping it silent in case of failure.

    - FSNamesystem.allocateBlock()
    Placing pendingCreates.addBlock() inside the do-while-loop is confusing. Because you add block just once when it is valid.
    I'd propose to modify isValidBlock(b) so that it checked pendingCreates.contains(b) in addition to checking whether it is in the blocksMap.
    Then pendingCreates.addBlock() will need only to assert that the block is not pending.
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 8, 2007 at 8:15 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Attachment: (was: duplicateBlockId.patch)
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId2.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 8, 2007 at 8:15 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Attachment: duplicateBlockId2.patch

    Implemented all review comments except the one related to "better logging by abandonBlock". The reason i did not change it in this patch because it is not directly related to this issue and could conflict with another patch that I have outstanding. I am going to fix this logging issue as part of a separate JIRA issue.
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId2.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 8, 2007 at 8:15 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Status: Patch Available (was: Open)
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId2.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Tom White (JIRA) at Jun 15, 2007 at 8:17 am
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505087 ]

    Tom White commented on HADOOP-1444:
    -----------------------------------

    Dhruba,

    This patch no longer cleanly applies to trunk (due to HADOOP-1269?). Could you regenerate it please?
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId2.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 15, 2007 at 5:16 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Attachment: duplicateBlockId3.patch

    Merged patch with latest trunk.
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId3.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • dhruba borthakur (JIRA) at Jun 15, 2007 at 5:16 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    dhruba borthakur updated HADOOP-1444:
    -------------------------------------

    Attachment: (was: duplicateBlockId2.patch)
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Attachments: duplicateBlockId3.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.
  • Doug Cutting (JIRA) at Jun 18, 2007 at 10:47 pm
    [ https://issues.apache.org/jira/browse/HADOOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Doug Cutting updated HADOOP-1444:
    ---------------------------------

    Resolution: Fixed
    Fix Version/s: 0.14.0
    Status: Resolved (was: Patch Available)

    I just committed this. Thanks, Dhruba!

    Note: your patch included some improvements to the descriptions in conf/hadoop-default.xml, but these seemed unrelated to this issue and I assume were intended for some other issue and included only accidentally, so I ignored them.
    Block allocation method does not check pendingCreates for duplicate block ids
    -----------------------------------------------------------------------------

    Key: HADOOP-1444
    URL: https://issues.apache.org/jira/browse/HADOOP-1444
    Project: Hadoop
    Issue Type: Bug
    Components: dfs
    Reporter: dhruba borthakur
    Assignee: dhruba borthakur
    Fix For: 0.14.0

    Attachments: duplicateBlockId3.patch


    The HDFS namenode allocates a new random blockid when requested. It then checks the blocksMap to verify if this blockid is already in use. If this block is is already in use, it generates another random number and above process continues. When a blocksid that does not exist in the blocksMap is found, it stores this blocksid in pendingCreateBlocks and returns the blocksid to the requesting client.
    The above check for detecting duplicate blockid should check pendingCreateBlocks as well.
    A related problem exists when a file is deleted. Deleting a file causes all its blocks to be deleted from the blocksMap immediately. These blockids move to recentInvalidateSets and are sent out to the corresponding datanodes as part of responses to succeeding heartbeats. So, there is a time window when a block exists in the datanode but not in the blocksMap. At this time, if the blockid-random-number generator generates a blockid that exists in the datanode but not on the blocksMap, then the namenode will fail to detect that this is a duplicate blockid.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcommon-dev @
categorieshadoop
postedMay 30, '07 at 5:30p
activeJun 18, '07 at 10:47p
posts11
users1
websitehadoop.apache.org...
irc#hadoop

1 user in discussion

Doug Cutting (JIRA): 11 posts

People

Translate

site design / logo © 2022 Grokbase