[SERVER-10447] dropDatabase() doesn't know about symlinks Created: 07/Aug/13 Updated: 09/Jul/16 Resolved: 02/Mar/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Nathan Rosenquist | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Steps To Reproduce: | Here is an example of the current behavior in action, using MongoDB 2.4.5: [user@mongo ~]$ ls -lh /var/mongo/data/ [user@mongo ~]$ ls -lh /u0/mydb01/ > use mydb01 > db.mydb01.insert( {"a":"b"}) [user@mongo ~]$ ls -lh /var/mongo/data/ [user@mongo ~]$ ls -lh /u0/mydb01/ ---------- Here is an example of this behavior in action, using MongoDB 2.4.5, patched to preserve [user@mongo ~]$ ls -lh /var/mongo/data/ [user@mongo ~]$ ls -lh /u0/mydb01/ > use mydb01 > db.mydb01.insert( {"a":"b"}) [user@mongo ~]$ ls -lh /var/mongo/data/ [user@mongo ~]$ ls -lh /u0/mydb01/ |
| Participants: |
| Description |
|
First of all, thanks for developing MongoDB, and releasing it as open source software! We have been using MongoDB with the --directoryperdb option, and it's been running great. As the data in the system has expanded, we added some additional hard drives to the server, to reduce spindle contention and increase the amount o Recently, we discovered that if you drop such a database from the Mongo shell, Mongo will simply remove the symlink, without dereferencing it. The end result is that the symlink goes away, and the data on the additional drive becomes orphaned. Worse, if you later recreate or otherwise try to access the same database again, Mongo has no memory of the symlink or the other drive, and creates the database anew. The end result is that under this configuration, if you drop and then re-add such a database, the new data will be written to the original drive. I have attached a patch to MongoDB 2.4.5 that changes this behavior. In normal circumstances, it should work just as it did before. However, in the situation described above, MongoDB will instead follow the symlink, and remove the contents of the target directory instead. The theory is that since the symlink was placed there by a system administrator, it will be left alone. This makes creating and deleting a database a symmetrical operation from the Mongo shell. Creating and deleting the symlink and provisioning additional hard drives is also a symmetrical operation for the system administrator. |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 02/Mar/14 ] |
|
I'm marking this a duplicate of |
| Comment by Nathan Rosenquist [ 07/Aug/13 ] |
|
Thanks for the detailed reply Stephen. I'll have to revisit this later when I'm not on a deadline. Thanks, |
| Comment by Stennie Steneker (Inactive) [ 07/Aug/13 ] |
|
Hi Nathan, Thank you for raising this issue and including a code contribution. Have you read our guide to Contributing to the MongoDB project? There are a few extra steps that will help this request be ready for review by our kernel team:
Rather than providing a patch file, contributions are normally done via a pull request on Github:
Regards, |
| Comment by Nathan Rosenquist [ 07/Aug/13 ] |
|
FYI, It seems this issue is somewhat related to Thanks again! |