Messages in this thread | | | Date | Tue, 27 Mar 2007 12:34:22 -0700 | From | Andrew Morton <> | Subject | Re: [patch resend v4] update ctime and mtime for mmaped write |
| |
On 27 Mar 2007 15:24:52 -0400 linux@horizon.com 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |