> 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. > > FADV_WILLSYNC is already implemented: sync_file_range() with > SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE. That will block in > a few circumstances, but maybe that's inevitable. There's actually a basic difference between a system call that says "initiate writeout" and one that says, "I plan to sync this soon," even if they have the same results in practice. (And Nick's "I won't write any time soon" idea is yet another). Though reasonable minds differ, the advice-to-kernel approach to managing file caches seems to be winning over instructions-to-kernel, and I personally much prefer it. > I think you're saying call FADV_WILLSYNC first on all the ranges, then > call fsync_range() on each range in turn to wait for the I/O to be > complete Right. The later calls tend to return immediately, of course. >- although that will cause unnecessary I/O barriers, one per >fsync_range(). What do I/O barriers have to do with it? An I/O barrier says, "don't harden later writes before these have hardened," whereas fsync_range() says, "harden these writes now." Does Linux these days send an I/O barrier to the block subsystem and/or device as part of fsync()? Or are we talking about the command to the device to harden all earlier writes (now) against a device power loss? Does fsync() do that? Either way, I can see that multiple fsync_ranges's in a row would be a little worse than just one, but it's pretty bad problem anyway, so I don't know if you could tell the difference. -- 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
