[SERVER-20331] Fix backup_restore.js test for RocksDB storage engine Created: 09/Sep/15 Updated: 07/Oct/15 Resolved: 25/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Igor Canadi | Assignee: | David Hows |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
In backup_restore.js test, it's assumed that non-wiredtiger engine supports fsyncLock. RocksDB doesn't support fsyncLock, so can we please also add RocksDB to line 288: https://github.com/mongodb/mongo/blob/master/jstests/noPassthrough/backup_restore.js#L288 |
| Comments |
| Comment by Igor Canadi [ 25/Sep/15 ] | ||||
|
Thanks David! | ||||
| Comment by David Hows [ 25/Sep/15 ] | ||||
|
I've restructured this test somewhat. The test will now check if the storage engine supports fsyncLock before performing a test. There is still a further issue within this test, as I found it would fail at times when running the rolling rsync test under MMAPv1. This issue has been raised as This is an example run with rolling enabled under MMAP: The following errors can be seen
| ||||
| Comment by David Hows [ 10/Sep/15 ] | ||||
|
Have added this to the commit for | ||||
| Comment by Daniel Pasette (Inactive) [ 09/Sep/15 ] | ||||
|
David, can you address this as part of your work supporting fsyncLock with WT? |