On Thu, Jul 28, 2011 at 02:41:02PM +0200, Kevin Wolf wrote:
More or less. There's one corner case for all Linux I/O, and that is
only writes up to INT_MAX are supported, and larger writes (and reads)
get truncated to it. It's pretty nasty, but Linux has been vocally
opposed to fixing
On Thu, Jul 28, 2011 at 1:15 PM, Christoph Hellwig h...@lst.de wrote:
On Thu, Jul 28, 2011 at 09:47:05AM +0200, Kevin Wolf wrote:
Indeed. This has come up a few times, and actually is a mostly trivial
task. Maybe we should give up waiting for -blockdev and separate cache
mode settings and
Am 27.07.2011 21:57, schrieb Christoph Hellwig:
On Wed, Jul 27, 2011 at 09:52:51PM +0200, Frediano Ziglio wrote:
Also I notice that combining XFS, Linux AIO, O_DIRECT and O_DSYNC give
impressive performance but currently there is no way to specify all that
flags together cause nocache enable
On Thu, Jul 28, 2011 at 09:47:05AM +0200, Kevin Wolf wrote:
Indeed. This has come up a few times, and actually is a mostly trivial
task. Maybe we should give up waiting for -blockdev and separate cache
mode settings and allow a nocache-writethrough or similar mode now? It's
going to be
Am 28.07.2011 14:15, schrieb Christoph Hellwig:
Christoph, on another note: Can we rely on Linux AIO never returning
short writes except on EOF? Currently we return -EINVAL in this case, so
short reads I meant, of course.
I hope it's true or we wouldn't return the correct error code.
More
Did you test this at all?
On Wed, Jul 27, 2011 at 08:25:25PM +0200, Frediano Ziglio wrote:
+case QEMU_AIO_FLUSH:
+io_prep_fdsync(iocbs, fd);
+break;
Looks great, but doesn't work as expected.
Hint: grep for aio_fsync in the linux kernel.
Il giorno 27/lug/2011, alle ore 20:31, Christoph Hellwig h...@lst.de ha
scritto:
Did you test this at all?
Yes! Not at kernel level :-)
Usually I trust documentation and man pages.
On Wed, Jul 27, 2011 at 08:25:25PM +0200, Frediano Ziglio wrote:
+case QEMU_AIO_FLUSH:
+
On Wed, Jul 27, 2011 at 09:52:51PM +0200, Frediano Ziglio wrote:
Yes! Not at kernel level :-)
In that case we have a bad error handling problem somewhere in qemu.
the IOCB_CMD_FDSYNC aio opcode will always return EINVAL currently,
and we really should have cought that somewhere in qemu.
