On Mon, Mar 26, 2012 at 02:40:47PM -0500, Richard Laager wrote:
On Sat, 2012-03-24 at 16:27 +0100, Christoph Hellwig wrote:
has_discard = !fallocate(s-fd, FALLOC_FL_PUNCH_HOLE |
FALLOC_FL_KEEP_SIZE,
There is no point in using FALLOC_FL_KEEP_SIZE together with
Am 26.03.2012 21:40, schrieb Richard Laager:
On Sat, 2012-03-24 at 16:30 +0100, Christoph Hellwig wrote:
On Wed, Mar 14, 2012 at 01:14:18PM +0100, Paolo Bonzini wrote:
Note that the discard granularity is only a hint, so it's really more a
maximum suggested value than a granularity. Outside
On Sat, Mar 24, 2012 at 04:29:26PM +0100, Christoph Hellwig wrote:
On Wed, Mar 14, 2012 at 01:01:35PM +0100, Kevin Wolf wrote:
Paolo mentioned a use case as a fast way for guests to write zeros, but
is it really faster than a normal write when we have to emulate it by a
bdrv_write with a
On Mon, Mar 26, 2012 at 10:44:07AM +0100, Daniel P. Berrange wrote:
This suggests that there be a new command line param to '-drive' to turn
discard support on/off, since QEMU can't reliably know if the raw file
it is given is intended to be fully pre-allocated by the mgmt app.
Yes.
On Sat, 2012-03-24 at 16:27 +0100, Christoph Hellwig wrote:
has_discard = !fallocate(s-fd, FALLOC_FL_PUNCH_HOLE |
FALLOC_FL_KEEP_SIZE,
There is no point in using FALLOC_FL_KEEP_SIZE together with
FALLOC_FL_PUNCH_HOLE.
It's *required*. From the man page [0], The
On Sat, 2012-03-24 at 16:30 +0100, Christoph Hellwig wrote:
On Wed, Mar 14, 2012 at 01:14:18PM +0100, Paolo Bonzini wrote:
Note that the discard granularity is only a hint, so it's really more a
maximum suggested value than a granularity. Outside of a cluster
boundary the format would
On Sat, Mar 10, 2012 at 12:02:40PM -0600, Richard Laager wrote:
If we could probe for FALLOC_FL_PUNCH_HOLE support, then we could avoid
advertising discard support based on FALLOC_FL_PUNCH_HOLE when it is not
going to work. This would side step these problems. You said it wasn't
possible to
On Wed, Mar 14, 2012 at 01:01:35PM +0100, Kevin Wolf wrote:
Paolo mentioned a use case as a fast way for guests to write zeros, but
is it really faster than a normal write when we have to emulate it by a
bdrv_write with a temporary buffer of zeros? On the other hand we have
the cases where
On Wed, Mar 14, 2012 at 01:14:18PM +0100, Paolo Bonzini wrote:
Note that the discard granularity is only a hint, so it's really more a
maximum suggested value than a granularity. Outside of a cluster
boundary the format would still have to write zeros manually.
Also, Linux for example
On Wed, Mar 14, 2012 at 01:49:48PM +0100, Paolo Bonzini wrote:
It does make the distinction. I don't care is UNMAP (or WRITE
SAME(16) with the UNMAP bit set); I want to have zeroes is WRITE
SAME(10) or WRITE SAME(16) with an all-zero payload.
But once the taget sets the unmap zeroes data bit
Il 16/03/2012 01:47, Richard Laager ha scritto:
On Thu, 2012-03-15 at 10:36 +0100, Paolo Bonzini wrote:
Changing across guest boots is a minor problem, but changing across
migration must be avoided at all costs.
BTW, after this discussion I think we can instead report
discard_granularity =
Il 15/03/2012 01:42, Richard Laager ha scritto:
It is worse in that we do not want the hardware parameters exposed to the
guest to change behind the scenes, except if you change the machine type
or if you use the default unversioned type.
You're saying that discard_granularity and
On Thu, 2012-03-15 at 10:36 +0100, Paolo Bonzini wrote:
Changing across guest boots is a minor problem, but changing across
migration must be avoided at all costs.
BTW, after this discussion I think we can instead report
discard_granularity = 512 and discard_zeroes_data=0 and get most of the
On Wed, 2012-03-14 at 08:41 +0100, Paolo Bonzini wrote:
Il 13/03/2012 20:13, Richard Laager ha scritto:
* For SCSI, report an unmap_granularity to the guest as follows:
max(logical_block_size, discard_granularity) /
logical_block_size
This is more or less already
Am 14.03.2012 08:41, schrieb Paolo Bonzini:
Il 13/03/2012 20:13, Richard Laager ha scritto:
If you have a new kernel that supports SEEK_HOLE/SEEK_DATA, it can also
be done by skipping the zero write on known holes.
This could even be done at the block layer level using bdrv_is_allocated.
Il 14/03/2012 13:01, Kevin Wolf ha scritto:
Am 14.03.2012 08:41, schrieb Paolo Bonzini:
Il 13/03/2012 20:13, Richard Laager ha scritto:
If you have a new kernel that supports SEEK_HOLE/SEEK_DATA, it can also
be done by skipping the zero write on known holes.
This could even be done at the
Am 14.03.2012 13:14, schrieb Paolo Bonzini:
Paolo mentioned a use case as a fast way for guests to write zeros, but
is it really faster than a normal write when we have to emulate it by a
bdrv_write with a temporary buffer of zeros?
No, of course not.
On the other hand we have
the cases
Il 14/03/2012 13:37, Kevin Wolf ha scritto:
Am 14.03.2012 13:14, schrieb Paolo Bonzini:
Paolo mentioned a use case as a fast way for guests to write zeros, but
is it really faster than a normal write when we have to emulate it by a
bdrv_write with a temporary buffer of zeros?
No, of course
Am 14.03.2012 13:49, schrieb Paolo Bonzini:
Il 14/03/2012 13:37, Kevin Wolf ha scritto:
Am 14.03.2012 13:14, schrieb Paolo Bonzini:
Paolo mentioned a use case as a fast way for guests to write zeros, but
is it really faster than a normal write when we have to emulate it by a
bdrv_write with a
On Mon, 2012-03-12 at 10:34 +0100, Paolo Bonzini wrote:
To be completely correct, I suggest the following behavior:
1. Add a discard boolean option to the disk layer.
2. If discard is not specified:
* For files, detect a true/false value by comparing
Il 10/03/2012 19:02, Richard Laager ha scritto:
I propose adding the following behaviors in any event:
* If a QEMU block device reports a discard_granularity 0, it
must be equal to 2^n (n = 0), or QEMU's block core will change
it to 0. (Non-power-of-two granularities are
Am 12.03.2012 13:27, schrieb Paolo Bonzini:
Il 10/03/2012 19:02, Richard Laager ha scritto:
I propose adding the following behaviors in any event:
* If a QEMU block device reports a discard_granularity 0, it
must be equal to 2^n (n = 0), or QEMU's block core will change
I'm believe your patch set provides these behaviors now:
* QEMU block drivers report discard_granularity.
* discard_granularity = 0 means no discard
* The guest is told there's no discard support.
* discard_granularity 0 is undefined.
Am 08.03.2012 18:15, schrieb Paolo Bonzini:
Remove the bdrv_co_write_zeroes callback. Instead use the discard
information from bdrv_get_info to choose between bdrv_co_discard
and a normal write.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
I'm not sure if this a good idea.
The goal of
Il 09/03/2012 17:37, Kevin Wolf ha scritto:
Remove the bdrv_co_write_zeroes callback. Instead use the discard
information from bdrv_get_info to choose between bdrv_co_discard
and a normal write.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
I'm not sure if this a good idea.
The
Remove the bdrv_co_write_zeroes callback. Instead use the discard
information from bdrv_get_info to choose between bdrv_co_discard
and a normal write.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block.c | 12 +---
block/qed.c |8
block_int.h |8
26 matches
Mail list logo
