[SERVER-17703] dropDatabase not removing folders with wiredTiger Created: 23/Mar/15 Updated: 15/Jun/20 Resolved: 01/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | 3.0.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Chad Kreimendahl | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
When doing a dropDatabase() using MMAPv1 on versions from 2.4 -> 3.0.1, the relevant folders which contain the data when using directoryPerDB: true are also removed. However, when performing the same dropDatabase using the wiredTiger engine and directoryPerDB: true, the directories are left in-tact, and only the related files are removed. (note, only tested with directoryForIndexes: true in 3.0.1) |
| Comments |
| Comment by Michael Brenden [ 20/Oct/19 ] |
|
ditto "Feature request / Improvement request: |
| Comment by Johannes Richter [ 07/Mar/16 ] |
|
Dear team, Feature request / Improvement request: Best regards, |
| Comment by Daniel Pasette (Inactive) [ 01/Jul/15 ] |
|
Have decided to not fix and instead change MMAP to be consistent with what WiredTiger already does. |
| Comment by Chad Kreimendahl [ 30/Jun/15 ] |
|
Works for me. I was just looking for consistency more than anything. |
| Comment by Daniel Pasette (Inactive) [ 30/Jun/15 ] |
|
sallgeud, I found this related issue from the archives: Furthermore, if you have a symlink pointing to a directory within a separate volume, calling dropDatabase only deletes the symlink, it doesn't actually delete the data files – which I think is a bug. If you then recreate the symlink without deleting the data files, mongodb with mmap will happily allow you to continue using the old datafiles. |
| Comment by Michael Cahill (Inactive) [ 24/Mar/15 ] |
|
One issue with this change is if the "directory" is in fact a symbolic link to another volume – if the link is removed by a drop then a subsequent create would make a directory on the wrong volume. I'll check exactly what happens with mmap_v1 – I agree that it would be good to match those semantics. |
| Comment by Chad Kreimendahl [ 23/Mar/15 ] |
|
I think this is entirely about maintenance for us. Other than the potential of having to check thousands of directories unnecessarily in the future, I don't imagine it's a bad issue. Of course, consistency is good.... as is cleanliness. Given that the directory has no purpose following a drop, it would make sense to remove it. In the event you've created a partition for it, the delete would return fine, but the mount would still appear, so no harm in that scenario would be caused. |
| Comment by Ramon Fernandez Marina [ 23/Mar/15 ] |
|
Thanks for the report sallgeud, I can reproduce with --directoryperdb as well, so we're investigating. Note that I couldn't see any ill-effects related to this behavior: I ran a quick test and I could re-create the database, create new collections, and add indexes as expected. While I can see the difference in behavior between storage engines, I wonder whether this behavior is a better choice than removing the directory since directoryperdb is commonly used to host different databases in different filesystems. |