Issue Details (XML | Word | Printable)

Key: HADOOP-9
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Ari Rabkin
Reporter: Paul Baclace
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Hadoop Common

mapred.local.dir temp dir. space allocation limited by smallest area

Created: 17/Jan/06 10:09 AM   Updated: 08/Jul/09 04:52 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: 0.19.0

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works hadoop9.patch 2008-07-21 10:53 PM Ari Rabkin 7 kB
Environment: all

Hadoop Flags: Reviewed
Resolution Date: 12/Aug/08 09:21 PM


 Description  « Hide
When mapred.local.dir is used to specify multiple temp dir. areas, space allocation limited by smallest area because the temp dir. selection algorithm is "round robin starting from a randomish point". When round robin is used with approximately constant sized chunks, the smallest area runs out of space first, and this is a fatal error.

Workaround: only list local fs dirs in mapred.local.dir with similarly-sized available areas.

I wrote a patch to JobConf (currenly being tested) which uses df to check available space (once a minute or less often) and then uses an efficient roulette selection to do allocation weighted by magnitude of available space.



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Ari Rabkin added a comment - 17/Jul/08 03:39 PM
This is a less pressing issue these days, since you can pass a size to the local dir allocator and it'll do the right thing.
Do people think this is still worth fixing? It should be straightforward to do something roulette-y in LocalDirAllocator.getLocalPathForWrite for unknown-size writes.

Ari Rabkin added a comment - 21/Jul/08 10:53 PM
Patch fixing this issue.

Ari Rabkin added a comment - 21/Jul/08 10:55 PM
downgrading priority

Hadoop QA added a comment - 22/Jul/08 03:04 AM
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12386584/hadoop9.patch
against trunk revision 678593.

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

+1 tests included. The patch appears to include 3 new or modified tests.

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

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

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

+1 release audit. The applied patch does not increase the total number of release audit warnings.

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

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

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

This message is automatically generated.


Owen O'Malley added a comment - 12/Aug/08 09:21 PM
I just committed this. Thanks, Ari!

Hudson added a comment - 22/Aug/08 12:34 PM