Prev: bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
Next: fix corruption of hibernation caused by reusing swap at saving image
From: Jeff Moyer on 5 Aug 2010 15:20 "Ted Ts'o" <tytso(a)mit.edu> writes: > On Thu, Aug 05, 2010 at 05:20:12AM +0300, Avi Kivity wrote: >> >> Why not? To be clear, I'm talking about an io_submit() with >> multiple IO_CMD_FSYNC requests, with a kernel implementation that is >> able to batch these requests. > > IO_CMD_FSYNC doesn't exist right now, but sure, it means we don't have Well, there's IOCB_CMD_FSYNC. But still, this isn't the same thing as what's requested. If I understand correctly, what is requested is a mechanism to flush out all data for multiple file descriptors and follow that with a single barrier/flush (and yes, Ted did give a summary of the commands that would be required to accomplish that). There still remains the question of why this should be tied to the AIO submission interface. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Moyer on 5 Aug 2010 16:50
"Ted Ts'o" <tytso(a)mit.edu> writes: > On Thu, Aug 05, 2010 at 03:13:44PM -0400, Jeff Moyer wrote: >> > IO_CMD_FSYNC doesn't exist right now, but sure, it means we don't have >> >> Well, there's IOCB_CMD_FSYNC. But still, this isn't the same thing as >> what's requested. If I understand correctly, what is requested is a >> mechanism to flush out all data for multiple file descriptors and follow >> that with a single barrier/flush (and yes, Ted did give a summary of the >> commands that would be required to accomplish that). >> >> There still remains the question of why this should be tied to the AIO >> submission interface. > > I don't think it should, personally. The only excuse might be if > someone wanted to do an asynchronous fsync(), but I don't think that > makes sense in most cases. In case it wasn't clear, we are in agreement on this. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |