Nick Piggin <npiggin@xxxxxxx> wrote on 01/20/2009 05:36:06 PM: > On Tue, Jan 20, 2009 at 01:25:59PM -0800, Bryan Henderson wrote: > > > For this, taking a vector of multiple ranges would be nice. > > > Alternatively, issuing parallel fsync_range calls from multiple > > > threads would approximate the same thing - if (big if) they aren't > > > serialised by the kernel. > > > > That sounds like a job for fadvise(). A new FADV_WILLSYNC says you're > > planning to sync that data soon. The kernel responds by scheduling the > > I/O immediately. fsync_range() takes a single range and in this case is > > just a wait. I think it would be easier for the user as well as more > > flexible for the kernel than a multi-range fsync_range() or multiple > > threads. > > A problem is that the kernel will not always be able to schedule the > IO without blocking (various mutexes or block device queues full etc). I don't really see the problem with that. We're talking about a program that is doing device-synchronous I/O. Blocking is a way of life. Plus, the beauty of advice is that if it's hard occasionally, the kernel can just ignore it. > And it takes multiple system calls. When you're reading, the system call overhead is significant in an operation that just copies from memory to memory, so we have readv() and accept the added complexity and harder to use interface. When you're syncing a file, you're running so slowly that I doubt the overhead of multiple system calls is noticeable. There are a lot of other multiple system call sequences I would try to replace with one complex one before worrying about multi-range file sync. -- Bryan Henderson IBM Almaden Research Center San Jose CA Storage Systems -- 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
