[SERVER-3430] Exception while running a command-line repair Created: 15/Jul/11 Updated: 30/Mar/12 Resolved: 12/Sep/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Tools |
| Affects Version/s: | 1.8.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrew Huling | Assignee: | Aaron Staple |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Amazon Linux |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | Linux | ||||||||
| Participants: | |||||||||
| Description |
|
I ran a command-line repair on one server in 2 server+arbiter replica set to try to reclaim some disk space and got the following error: [initandlisten] Assertion: 10446:mmap: can't map area of size 0 file: /data/db/_tmp/esort.1310694712.469162920//file.9 The repair was successful on the other server. |
| Comments |
| Comment by Aaron Staple [ 12/Sep/11 ] |
|
I think it might be |
| Comment by Aaron Staple [ 05/Sep/11 ] |
|
Hi Andrew - is it possible /data/db ran out of space during the repair? Mongod would have put some temporary files in there. |
| Comment by Andrew Huling [ 18/Jul/11 ] |
|
Here it is. Thank you for your help! |
| Comment by Eliot Horowitz (Inactive) [ 18/Jul/11 ] |
|
Can you attach the full log file? |
| Comment by Andrew Huling [ 18/Jul/11 ] |
|
That is correct. It looks to me like it is looking for a file in that directory, not finding it, and then as part of the process trying to use that non-existent (size 0) file somewhere as a result. But I really have no idea what I'm talking about so I could be way off. |
| Comment by Eliot Horowitz (Inactive) [ 18/Jul/11 ] |
|
And nothing in /data/db/_tmp/? |
| Comment by Andrew Huling [ 18/Jul/11 ] |
|
Here is the ls -la of those directories when it errs out: [ahuling@mongo01.i.staging.gamechanger.io $tmp_repairDatabase_0]$ ls -la |
| Comment by Eliot Horowitz (Inactive) [ 18/Jul/11 ] |
|
Ah yes. |
| Comment by Andrew Huling [ 18/Jul/11 ] |
|
I'm running it now and there appears to be nothing in that directory still. However, I realized that you might not be aware that I am running the repair with the repairpath option specified. In that directory, there are 5 sub-directories $tmp_repairDatabase_0 - $tmp_repairDatabase_4. In those directories, there are a bunch of non-zero sized files named for the database being backed up. Let me know if you'd like more detail about that directory. |
| Comment by Eliot Horowitz (Inactive) [ 17/Jul/11 ] |
|
Can you try the repair again and send ls -la of the tmp? |
| Comment by Andrew Huling [ 17/Jul/11 ] |
|
It is still failing. |
| Comment by Eliot Horowitz (Inactive) [ 17/Jul/11 ] |
|
Is it still failing or did it eventually work? |
| Comment by Andrew Huling [ 15/Jul/11 ] |
|
The directory no longer exists. I did run that command at least once after the repair process had failed (I ran the process multiple times to see if the problem continued to happen) when the _tmp directory was there, but it was empty. |
| Comment by Eliot Horowitz (Inactive) [ 15/Jul/11 ] |
|
Can you do a ls -la on /data/db/_tmp/ if it still exists |
| Comment by Andrew Huling [ 15/Jul/11 ] |
|
I don't think there was ever an unclean shutdown and I am running with journaling. |
| Comment by Eliot Horowitz (Inactive) [ 15/Jul/11 ] |
|
Was there ever an unclean shutdown? |