Integrated in Hadoop-trunk #378 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/378/)

I just committed this. Thank you Nicholas.

2633_20080123.patch: put fsck unit tests back to one class, updated with current trunk.

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12373782/2633_20080122.patch
against trunk revision r614413.

@author +1. The patch does not contain any @author tags.

javadoc +1. The javadoc tool did not generate any warning messages.

javac +1. The applied patch does not generate any new compiler warnings.

findbugs +1. The patch does not introduce any new Findbugs warnings.

core tests +1. The patch passed core unit tests.

contrib tests -1. The patch failed contrib unit tests.

Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1681/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1681/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1681/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1681/console

This message is automatically generated.

2633_20080122.patch: rewrite TestFsck so that MiniDFSCluster is shutdown properly between each test.

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12373551/2633_20080118.patch
against trunk revision r613359.

@author +1. The patch does not contain any @author tags.

javadoc +1. The javadoc tool did not generate any warning messages.

javac +1. The applied patch does not generate any new compiler warnings.

findbugs +1. The patch does not introduce any new Findbugs warnings.

core tests -1. The patch failed core unit tests.

contrib tests -1. The patch failed contrib unit tests.

Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1654/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1654/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1654/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1654/console

This message is automatically generated.

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12373464/2633_20080117c.patch
against trunk revision r613115.

@author +1. The patch does not contain any @author tags.

javadoc +1. The javadoc tool did not generate any warning messages.

javac +1. The applied patch does not generate any new compiler warnings.

findbugs +1. The patch does not introduce any new Findbugs warnings.

core tests -1. The patch failed core unit tests.

contrib tests -1. The patch failed contrib unit tests.

Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1639/testReport/
Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1639/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1639/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1639/console

This message is automatically generated.

This change should be very low risk--fsck either works or it doesn't. There
was a lot more risk in the new code!

In this context, make sure you've taken a peek at

https://issues.apache.org/jira/browse/HADOOP-2632

Does a test need to be written for this? It's not clear how easy that would be.

+1

2633_20080117c.patch: re-arranged some codes.

2633_20080117b.patch: updated with trunk

2633_20080117.patch: incorporated all suggestions. Thanks, Konstantin.

• nn.namesystem.now() should be FSNamesystem.now()
• Methods should be separate by a blank line.
• there is to many methods called getBlockLocationsInternal(). It took me at least 20 minutes to understand who is calling whom. Traditionally the general idea of methods and their *Internal counterparts is to distinguish between the api methods and their synchronized parts. Synchronized part of the implementation is usually called *Internal. It is also supposed to be private.

I propose the following modifications here:

• getBlockLocationsInternal(String src,long,long) should be renamed to getBlockLocations(String src,long,long) because you need to call ii in NamenodeFsck.
• getBlockLocationsInternal(String clientMachine,String src,long,long) should be removed and the sorting part of it should be placed directly into getBlockLocations(String clientMachine,String src,long,long).
• the private getBlockLocationInternal(INodeFile, ...) should be renamed to getBlockLocationsInternal(INodeFile, ...) with an 's' in the middle. This was probably my fault.

As a result you will have only one private synchronized getBlockLocationsInternal() and two getBlockLocations().

2633_20080116.patch: access NameNode by (local) method calls instead of RPC.