[
https://issues.apache.org/jira/browse/HADOOP-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699800#action_12699800
]
Tsz Wo (Nicholas), SZE commented on HADOOP-5467:
------------------------------------------------
Got a taste of oiv. This is going to be very useful.
Some comments on the CLI:
- The default output file is not clear. Different processors may generate
different output files. If the output file already exist, oiv overwrites the
file silently. oiv should require either -o or -printToScreen but not assuming
a default output file.
- The help should show some single line format. e.g.
{noformat}
$ cp --help
Usage: cp [OPTION]... SOURCE DEST
or: cp [OPTION]... SOURCE... DIRECTORY
or: cp [OPTION]... --target-directory=DIRECTORY SOURCE...
Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.
{noformat}
- The doc says "Ls is the default output format .. Therefore, it is not
possible to directly compare the output of the lsr command this this tool. In
order to correctly determine the size of files, the Ls processor requires and
overrides disabling the -skipBlocks option."
-* Is Ls a output processor or a output format? The doc refers the processors
as formats several times. Personally, I like the name "format" better.
Anyway, we should consistently use one of them.
-* Seems to me that Ls does not show block information.
- You should mention in the doc that the tool doesn't need a running cluster to
work.
- Typos in the doc: "[-i|-inputFile]" should be "[-i|--inputFile]". Similarly,
for the other flags.
Will give some code review soon.
> Create an offline fsimage image viewer
> --------------------------------------
>
> Key: HADOOP-5467
> URL: https://issues.apache.org/jira/browse/HADOOP-5467
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: Jakob Homan
> Assignee: Jakob Homan
> Attachments: fsimage.xml, fsimageV18, fsimageV19, HADOOP-5467.patch,
> HADOOP-5467.patch, HADOOP-5467.patch, HADOOP-5467.patch, HADOOP-5467.patch
>
>
> It would be useful to have a tool to examine/dump the contents of the fsimage
> file to human-readable form. This would allow analysis of the namespace
> (file usage, block sizes, etc) without impacting the operation of the
> namenode. XML would be reasonable output format, as it can be easily viewed,
> compressed and manipulated via either XSLT or XQuery.
> I've started work on this and will have an initial version soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
