On 05.02.20 19:39, Eric Blake wrote:
> On 2/5/20 11:22 AM, Max Reitz wrote:
>
>>
And thus callers which just want the trivially obtainable
BDRV_ZERO_TRUNCATE info have to wait for the BDRV_ZERO_OPEN inquiry,
even though they don’t care about that flag.
>>>
>>> True, but only to a mi
On 2/5/20 11:22 AM, Max Reitz wrote:
And thus callers which just want the trivially obtainable
BDRV_ZERO_TRUNCATE info have to wait for the BDRV_ZERO_OPEN inquiry,
even though they don’t care about that flag.
True, but only to a minor extent; and the documentation mentions that
the BDRV_ZERO
On 05.02.20 15:07, Eric Blake wrote:
> On 2/5/20 1:51 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> +typedef enum {
> + /*
> + * bdrv_known_zeroes() should include this bit if the contents of
> + * a freshly-created image with no backing file reads as all
> + * zer
On 04.02.20 20:03, Eric Blake wrote:
> On 2/4/20 11:53 AM, Max Reitz wrote:
>> On 31.01.20 18:44, Eric Blake wrote:
>>> Having two slightly-different function names for related purposes is
>>> unwieldy, especially since I envision adding yet another notion of
>>> zero support in an upcoming patch.
On 04.02.20 18:51, Eric Blake wrote:
> On 2/4/20 11:42 AM, Max Reitz wrote:
>
>>>
>>> I understand that this is preexisting logic, but could I ask: why?
>>> What's wrong
>>> if driver can guarantee that created file is all-zero, but is not sure
>>> about
>>> file resizing? I agree that it's normal
On 2/5/20 8:25 AM, Vladimir Sementsov-Ogievskiy wrote:
But when you truncate them (with PREALLOC_MODE_OFF, as
BlockDriver.bdrv_has_zero_init_truncate()’s comment explains), the new
area is always going to be 0, regardless of initial preallocation.
ah yes, due to qcow2 zero clusters.
Hmm. Do
05.02.2020 17:07, Eric Blake wrote:
On 2/5/20 1:51 AM, Vladimir Sementsov-Ogievskiy wrote:
+typedef enum {
+ /*
+ * bdrv_known_zeroes() should include this bit if the contents of
+ * a freshly-created image with no backing file reads as all
+ * zeroes without any additional effor
On 2/5/20 1:51 AM, Vladimir Sementsov-Ogievskiy wrote:
+typedef enum {
+ /*
+ * bdrv_known_zeroes() should include this bit if the contents of
+ * a freshly-created image with no backing file reads as all
+ * zeroes without any additional effort. If .bdrv_co_truncate is
+ * s
04.02.2020 20:42, Max Reitz wrote:
On 04.02.20 16:35, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch
On 2/4/20 11:53 AM, Max Reitz wrote:
On 31.01.20 18:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a mis
On 31.01.20 18:44, Eric Blake wrote:
> Having two slightly-different function names for related purposes is
> unwieldy, especially since I envision adding yet another notion of
> zero support in an upcoming patch. It doesn't help that
> bdrv_has_zero_init() is a misleading name (I originally thoug
On 2/4/20 11:42 AM, Max Reitz wrote:
I understand that this is preexisting logic, but could I ask: why?
What's wrong
if driver can guarantee that created file is all-zero, but is not sure
about
file resizing? I agree that it's normal for these flags to have the same
value,
but what is the reaso
On 04.02.20 16:35, Vladimir Sementsov-Ogievskiy wrote:
> 31.01.2020 20:44, Eric Blake wrote:
>> Having two slightly-different function names for related purposes is
>> unwieldy, especially since I envision adding yet another notion of
>> zero support in an upcoming patch. It doesn't help that
>> b
04.02.2020 18:49, Eric Blake wrote:
On 2/4/20 9:35 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patc
On 2/4/20 9:35 AM, Vladimir Sementsov-Ogievskiy wrote:
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zer
31.01.2020 20:44, Eric Blake wrote:
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a misleading name (I originally thought that
Having two slightly-different function names for related purposes is
unwieldy, especially since I envision adding yet another notion of
zero support in an upcoming patch. It doesn't help that
bdrv_has_zero_init() is a misleading name (I originally thought that a
driver could only return 1 when ope
17 matches
Mail list logo
