On Fri, Aug 06, 2010 at 12:13:56AM -0700, Darrick J. Wong wrote: > Yes, it's a proxy for something else. One of our larger products would like to > use fsync() to flush dirty data out to disk (right now it looks like they use > O_SYNC), but they're concerned that the many threads they use can create an > fsync() storm. So, they wanted to know how to mitigate the effects of those > storms. Not calling fsync() except when they really need to guarantee a disk > write is a good start, but I'd like to get ahead of them to pick off more low > hanging fruit like the barrier coordination and not sending barriers when > there's no dirty data ... before they run into it. :) Do they need a barrier operation, or do they just want to initiate the I/O? One of the reasons I found it hard to believe you would have multiple threads all fsync()'ing the same file is that keeping the the file consistent is very hard to do in such a scenario. Maintaining ACID-level consistency without a single thread which coordinates when commit records gets written is I'm sure theoretically possible, but in practice, I wasn't sure any applications would actually be _written_ that way. If the goal is just to make sure I/O is getting initiated, without necessarily waiting for assurance that a specific file write has hit the disk platters, it may be that the Linux-specific sync_file_range(2) system call might be a far more efficient way of achieving those ends. Without more details about what this product is doing, it's hard to say, of course. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
