Am 27.06.2013 um 15:11 hat Peter Lieven geschrieben:
> Signed-off-by: Peter Lieven
> ---
> block/iscsi.c | 80
> -
> 1 file changed, 56 insertions(+), 24 deletions(-)
>
> diff --git a/block/iscsi.c b/block/iscsi.c
> index a38a1bf..2e2455
Am 27.06.2013 um 15:11 hat Peter Lieven geschrieben:
> Signed-off-by: Peter Lieven
> ---
> block/iscsi.c | 80
> -
> 1 file changed, 56 insertions(+), 24 deletions(-)
> @@ -1175,6 +1187,26 @@ static int iscsi_open(BlockDriverState *bs, Q
Right.
I don't see any problem with your patch.
On Sat, Jul 6, 2013 at 3:15 PM, Peter Lieven wrote:
> ok, to sum up you see no potential problem with my patch to optimize write
> zeroes by
> unmap iff lbprz==1 and lbpme == 1 ?
ACK
>
> the alternative would be to use writesame16 and sent a z
ok, to sum up you see no potential problem with my patch to optimize write
zeroes by
unmap iff lbprz==1 and lbpme == 1 ?
the alternative would be to use writesame16 and sent a zero block. this would
allow
an optimization also if lbprz == 0. in this case i would not set the unmap bit.
peter
Am
The device MIGHT map or anchor the blocks after the unmap but it may
only do so if the blocks that become mapped are all zero.
So I think you can safely assume that if lbprz==1 then it will always
read back as zero no matter what happens internally in the target.
Either the block becomes unmapp
Il 04/07/2013 23:07, Peter Lieven ha scritto:
>
> Am 04.07.2013 um 14:37 schrieb Paolo Bonzini :
>
>> Il 03/07/2013 23:23, Peter Lieven ha scritto:
>>> BDC is not used. I had an implementation that sent multiple descriptors
>>> out, but
>>> at least for my storage the maximum unmap counts not fo
Am 04.07.2013 um 14:37 schrieb Paolo Bonzini :
> Il 03/07/2013 23:23, Peter Lieven ha scritto:
>> BDC is not used. I had an implementation that sent multiple descriptors out,
>> but
>> at least for my storage the maximum unmap counts not for each descriptors,
>> but for all
>> together. So in t
Il 03/07/2013 23:23, Peter Lieven ha scritto:
> BDC is not used. I had an implementation that sent multiple descriptors out,
> but
> at least for my storage the maximum unmap counts not for each descriptors,
> but for all
> together. So in this case we do not need the field at all. I forgot to re
Am 03.07.2013 um 05:43 schrieb ronnie sahlberg :
> max_unmap :
>
> If the target does not return an explicit limit for max_unmap it will
> return 0x which means "no limit".
>
thanks for the remark. i wasn't aware.
> I think you should add a check for max_unmap and clamp it down to
> s
max_unmap :
If the target does not return an explicit limit for max_unmap it will
return 0x which means "no limit".
I think you should add a check for max_unmap and clamp it down to
something sane.
Maybe a maximum of 128M ?
Same for bdc, that should also be checked and clamped down to sa
Signed-off-by: Peter Lieven
---
block/iscsi.c | 80 -
1 file changed, 56 insertions(+), 24 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index a38a1bf..2e2455d 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -54,6 +54,8 @@ typ
11 matches
Mail list logo
