[
https://issues.apache.org/jira/browse/HADOOP-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated HADOOP-5019:
----------------------------------
Assignee: zhangwei
Status: Open (was: Patch Available)
* The patch contains commented-out code; would you mind removing it?
* Ignoring the AccessControlException here is probably not correct:
{noformat}
+ } catch (AccessControlException e) {
+ e.printStackTrace();
+ // something went wrong getting this ugi...
+ LOG.warn(" - could not get ugi ");
+
+ }
{noformat}
Since fsck already enforces permissions after HADOOP-4268, is this the correct
way to do it?
* Is it necessary to make BlocksMap::getINode(Block) public?
I don't think Raghu's question about why this belongs in fsck was ever
answered...
> add querying block's info in the fsck facility
> ----------------------------------------------
>
> Key: HADOOP-5019
> URL: https://issues.apache.org/jira/browse/HADOOP-5019
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: zhangwei
> Assignee: zhangwei
> Priority: Minor
> Attachments: HADOOP-5019-2.patch, HADOOP-5019.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> As now the fsck can do pretty well,but when the developer happened to the log
> such Block blk_28622148 is not valid.etc
> We wish to know which file and the datanodes the block belongs to.It can be
> solved by running "bin/hadoop fsck -files -blocks -locations / | grep
> <blockid>" ,but as mentioned early in the HADOOP-4945 ,it's not an effective
> way in a big product cluster.
> so maybe we could do something to let the fsck more convenience .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
