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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
