[
https://issues.apache.org/jira/browse/HDFS-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lei (Eddy) Xu updated HDFS-7830:
--------------------------------
Attachment: HDFS-7830.001.patch
[~cmccabe] Thanks for the reviews. I updated the patch to address your comments.
bq. We shouldn't swallow the exception here in the unit tests.
Fixed.
bq. In the non-unit-test case, we do need to catch the exception and prevent it
from propagating, since then we won't see any other exceptions.
The {{IOException}} is captured from:
{code}
try {
fsVolume.addBlockPool(bpid, this.conf);
fsVolume.getVolumeMap(bpid, tempVolumeMap, ramDiskReplicaTracker);
} catch (IOException e) {
LOG.warn("Caught exception when adding " + fsVolume +
". Will throw later.", e);
exceptions.add(e);
}
And these {{IOE}}s are used in {{DataNode#refreshVolumes}} to build error
messages. It is still needed to be thrown. What do you think?
{code}
> DataNode does not release the volume lock when adding a volume fails.
> ---------------------------------------------------------------------
>
> Key: HDFS-7830
> URL: https://issues.apache.org/jira/browse/HDFS-7830
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode
> Affects Versions: 2.6.0
> Reporter: Lei (Eddy) Xu
> Assignee: Lei (Eddy) Xu
> Attachments: HDFS-7830.000.patch, HDFS-7830.001.patch
>
>
> When there is a failure in adding volume process, the {{in_use.lock}} is not
> released. Also, doing another {{-reconfig}} to remove the new dir in order to
> cleanup doesn't remove the lock. lsof still shows datanode holding on to the
> lock file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
