[SERVER-27433] Consider tagging tests that use fsyncLock with "requires_fsync_lock" Created: 15/Dec/16 Updated: 06/Dec/22 Resolved: 11/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | neweng, tig-evgconfig | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Tooling & Methods
|
| Participants: |
| Description |
|
There are tests in jscore that use db.fsyncLock() (that is, db.adminCommand({fsync: 1, lock: true}). These tests need to be manually added to the sharding jscore passthough suites as well as the parallel suite. It would be convenient to be able to simply tag these tests with something like
and have suites/variants that don't support fsyncLock explicitly exclude that tag in in etc/evergreen.yml. |
| Comments |
| Comment by Ryan Timmons [ 11/May/20 ] |
|
Closing as wont-fix to indicate that there is currently no intention of doing this. Please re-open if there is priority for this. Perhaps this change could self-service by an appropriate server team if this is necessary rather than having to go thru the STM prioritization queue. |
| Comment by Max Hirschhorn [ 30/May/17 ] |
|
I think we've been using the "requires_fsync" tag for this purpose already, although the ephemeralForTest storage engine supports the {fsync: 1, lock: 1} command as a result of the work in |