[ 
https://issues.apache.org/jira/browse/HDFS-13818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597519#comment-16597519
 ] 

Adam Antal commented on HDFS-13818:
-----------------------------------

Uploaded patch v3.

Tests now tests the in-disk dbs as well, and also check if the two outputs 
match. The tests highlighted that in case of the in-memory db we also need to 
keep track of the corrupted nodes, so I created a class for it.

Updated the doc with all the new features, and fixed typos. Can incorporate the 
doc v2 (uploaded just now) to the OIV Guide easily, if the documentation is 
clear and proper.

As for the memory and other questions, I'll do a further research and write my 
insights in another comment.

> Extend OIV to detect FSImage corruption
> ---------------------------------------
>
>                 Key: HDFS-13818
>                 URL: https://issues.apache.org/jira/browse/HDFS-13818
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: hdfs
>            Reporter: Adam Antal
>            Assignee: Adam Antal
>            Priority: Major
>         Attachments: HDFS-13818.001.patch, HDFS-13818.002.patch, 
> HDFS-13818.003.patch, OIV_CorruptionDetector_processor.001.pdf, 
> OIV_CorruptionDetector_processor.002.pdf
>
>
> A follow-up Jira for HDFS-13031: an improvement of the OIV is suggested for 
> detecting corruptions like HDFS-13101 in an offline way.
> The reasoning is the following. Apart from a NN startup throwing the error, 
> there is nothing in the customer's hand that could reassure him/her that the 
> FSImages is good or corrupted.
> Although real full checking of the FSImage is only possible by the NN, for 
> stack traces associated with the observed corruption cases the solution of 
> putting up a tertiary NN is a little bit of overkill. The OIV would be a 
> handy choice, already having functionality like loading the fsimage and 
> constructing the folder structure, we just have to add the option of 
> detecting the null INodes. For e.g. the Delimited OIV processor can already 
> use in disk MetadataMap, which reduces memory consumption. Also there may be 
> a window for parallelizing: iterating through INodes for e.g. could be done 
> distributed, increasing efficiency, and we wouldn't need a high mem-high CPU 
> setup for just checking the FSImage.
> The suggestion is to add a --detectCorruption option to the OIV which would 
> check the FSImage for consistency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to