![]() | |||||||||||||
Messages in this thread |
On Sun, Jan 06, 2002 at 07:49:05PM -0800, Andrew Morton wrote: > which is probably better than just ignoring it as we do at present. > I'll leave it as shown above unless there be objections. by design defintely better as shown than mainline. a MS_ASYNC currently doesn't work because the VM will never care flushing dirty mapped pages, first it will have to unmap them that will never happen unless there's low-on mem condition, while the filemap_fdatasync will ensure those pages will hit the disk asynchronously in a sane amount of time (depending on kupdate). MS_ASYNC manpage says an update is scheduled, currently it will instead never happen for example if the machine is idle and there's no vm swap etc... your change will fix it. > I'll wait until Marcelo looks like he has his head above water and > then send out the final version of the ramdisk, truncate and > fsync/msync patches, cc'ed to yourself and lkml. I'd like to release a new -aa within tomorrow afternoon with every known bug discussed in this thread fixed, so then I can concentrate back on another thing, so I'd like to get those new versions ASAP :) for the buffer_new thing I guess it's simpler to just change the semantics of it rather than allocating ram on the stack. Andrea - 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/ | ||||||||||||
| Last update: 2005-03-22 12:15 [from the cache] ©2003-2008 | |||||||||||||