Nick Piggin wrote: > Well, given that postgresql post that they need to sync multiple > files, I think fsyncv is a nice way forward. It can be used to > implement fsync_range too, which is slightly portable. Also, fsyncv on multiple files could issue just the one disk cache flush, if they're all to the same disk... [about sync_file_range] > If the queue fills up it has to block. It cannot schedule a thread > to write out asynchronously, etc. Because userspace is directing > how the implementation should work rather than the high level > intention. I agree that it's overly constraining, and pushes unnecessary tuning work into userspace. All these calls, btw, would be much more "optimisable" in the kernel if they were AIOs. Let the kernel decide things like how much to batch, how much to parallelise, and still have the hint which comes from AIO submission order (userspace threads doing synchronous I/O loses this bit). But that doesn't seem likely to happen because it's really quite hard. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
