[SERVER-22271] Invalid use of MS_ASYNC in msync() call Created: 22/Jan/16 Updated: 22/Feb/16 Resolved: 01/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.2 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Christian Hergert | Assignee: | Kyle Suarez |
| 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 | ||||||||
| Sprint: | Integration F (02/01/16), Integration 10 (02/22/16) | ||||||||
| Participants: | |||||||||
| Description |
|
I was taking a look through some old code momentarily today, and noticed an invalid use of msync(). I'm not sure how many people are using the old V1 storage implementation these days, but worth knowing about nonetheless. mongo/src/mongo/db/storage/mmap_v1/mmap_posix.cpp:271 calls msync() with an option to use MS_ASYNC or MS_SYNC based on the "bool sync" parameter. Unfortunately for everyone involved, MS_ASYNC is a no-op since the late 2.6 Linux days (as background sync is always enabled). So this doesn't expedite the process of flushing. Instead, the best option (if flushing is really that necessary under the async case) is probably to spawn a thread and perform the msync(MS_SYNC) there. Cheers! – Christian Hergert |
| Comments |
| Comment by Kyle Suarez [ 01/Feb/16 ] |
|
Thanks again chergert! |
| Comment by Githook User [ 01/Feb/16 ] |
|
Author: {u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'ksuarz@gmail.com'}Message: As of Linux 2.6.17, calling msync() with the MS_ASYNC flag neither starts I/O |
| Comment by Ramon Fernandez Marina [ 22/Jan/16 ] |
|
Thanks for your report chergert, we're sending this to the storage team for evaluation. |