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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:33 EST