[dm-devel] dm thin pool discarding

[Zdenek Kabelac]

Dne 10. 01. 19 v 12:40 Martin Wilck napsal(a):
> On Thu, 2019-01-10 at 10:18 +0100, Zdenek Kabelac wrote:
>> Dne 10. 01. 19 v 1:39 james harvey napsal(a):
>>>
>>> Q3 - Does a LVM thin volume zero out the bytes that are
>>> discarded?  At
>>> least for me, queue/discard_zeroes_data is 0.  I see there was
>>> discussion on the list of adding this back in 2012, but I'm not
>>> sure
>>> it was ever added for there to be a way to enable it.
>>
>> Unprovisioned chunks always appear as zeroed for reading.
>> Once you provision chunk (by write) for thin volume out of thin-pool
>> - it
>> depends on thin-pool target setting 'skip_zeroing'.
>>
>> So if zeroing is enabled (no skipping) - and you use larger chunks -
>> the
>> initial chunk provisioning becomes quite expensive - that's why lvm2
>> is by
>> default recommending to not use zeroing for chunk sizes > 512K.
> 
> Which begs the question why lvm zeroes at provisioning time, and not at
> discard time, where speed matters less (and the operation could be
> carried out lazily, taking care only that the discarded blocks aren't
> re-provisioned before they are zeroed).

There are few simple answers to this.

If 'zeroing' happens at the moment of provisioning - then if you use 'small 
chunks' like 64K or 128K - in many cases there is actually no-zeroing at all - 
as the chunk is fully written during provisioning time.

So in most cases there is no associated 'extra-cost'.

Of course if chunks are big  - this no longer applies and extra time is wasted 
while zeroes goes to 'unwritten' sectors.


  > So far my understanding was that even without zeroing, an LVM thin
> volume could be considered as a drive with "discard zeroes data"
> property. If there's a flaw in the argument below, please point it out
> to me.
>

As said - if you discard 'less then aligned' chunk - nothing happens,
so it cannot be takes as like it would be always zeroing...


> Now consider a VM that uses a dm-thin volume as storage. If this VM
> issues a discard operation on some chunk of data, future reads on the
> discarded chunks through the same LV will return 0 because these chunks
> have just become unprovisioned. That looks pretty much like "disard

Thin-pool current data structures makes some operation 'cheap' and some other 
quite expensive.

i.e. you could implement some sort of 'offline' zeroing where the chunks that 
are left unused in thin-pool are 'pre-zeroed' when thin-pool has a spare 
bandwidth - but the real benefit is 'questionable' as it has been already 
mentioned - with smaller chunksizes - there are typically not so big extra 
costs....  - it might have some effect with big chunks thought - but those are 
on the other hand very inefficient with snapshots - so it usually does not 
apply for VM users....


> The point I'm uncertain about is what happens if such a chunk is
> (re)provisioned by a partial write (say chunk size is 1M and only 512k
> is written). What data would dm-thin return from a read of the non-
> overwritten part of that chunk?

Clearly unwritten portions chunk are filled with zeroes.


Zdene