On 27 Mar 2007 15:24:52 -0400 [EMAIL PROTECTED] wrote: > > * MS_ASYNC does not start I/O (it used to, up to 2.5.67). > > Yes, I noticed. See > http://www.ussg.iu.edu/hypermail/linux/kernel/0602.1/0450.html > for a bug report on the subject February 2006.
Suggest you use msync(MS_ASYNC), then sync_file_range(SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE). The new (post 2.6.17) MAP_SHARED dirty-page semantics mean that the msync() isn't actually needed. > That's why this application is still running on 2.4. > > As I mentioned at the time, the SUS says: > (http://opengroup.org/onlinepubs/007908799/xsh/msync.html) > "When MS_ASYNC is specified, msync() returns immediately once all the > write operations are initiated or queued for servicing." > > You can argue that putting it on the dirty list constitutes "queued for > servicing", but the intent seems pretty clear to me: MS_ASYNC is supposed > to start the I/O. Although strict standards-ese parsing says that > either branch of an or is acceptable, it is a common English language > convention that the first alternative is preferred and the second > is a fallback. > > It makes sense in this case: start the write or, if that's not possible > (the disk is already busy), queue it for service as soon as the disk > is available. > > They perhaps didn't mandate it this strictly, but that's clearly the > intent. We can fix your application, and we'll break someone else's. I don't think it's solveable, really - the range of applications is so broad, and the "standard" is so vague as to be useless. This is why we've been extending these things with linux-specific goodies which permit applications to actually tell the kernel what they want to be done in a more finely-grained fashion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
