[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:
Related
related to SERVER-22378 Remove sync parameter from StorageEng... Closed
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: SERVER-22271 msync() with MS_ASYNC is a no-op

As of Linux 2.6.17, calling msync() with the MS_ASYNC flag neither starts I/O
nor marks pages dirty. See
https://github.com/torvalds/linux/blob/d1e41ff11941784f469f17795a4d9425c2eb4b7a/mm/msync.c#L20-L29.
Branch: master
https://github.com/mongodb/mongo/commit/17b0d57781f5badabe7ebb63ea4aa9899d537194

Comment by Ramon Fernandez Marina [ 22/Jan/16 ]

Thanks for your report chergert, we're sending this to the storage team for evaluation.

Generated at Thu Feb 08 03:59:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.