<div dir="ltr">Hi Zdenek,<div>Thanks for the reply. I have confirmation on the Zeroing of thin chunks, they are disabled.</div><div>And I followed it up further to post additional details I collected on the same write performance issue. The summary is, for buffered IO there seems to be way more IOs queued than by the configured limit (queue/nr_requests). The thin dm device is not honouring this limit and has so many excess IO in flight, that any sync IO eventually stalls for a very long time. The details are in the thread. Can you confirm if this is a known issue? And what workaround would you suggest? If not pointers, to possible areas to explore?</div><div> Regards </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 6, 2021 at 7:27 PM Zdenek Kabelac <<a href="mailto:zdenek.kabelac@gmail.com">zdenek.kabelac@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dne 06. 12. 21 v 7:11 Lakshmi Narasimhan Sundararajan napsal(a): > Bumping this thread, any inputs would be appreciated. > >>>>> Do you measure writes while provisioning thin chunks or on already provisioned >>>>> device? >>>>> >>>> >>>> Hi Zdenek, >>>> These are traditional HDDs. Both the thin pool data/metadata reside on >>>> the same set of drive(s). >>>> I understand where you are going with this, I will look further into >>>> defining the hardware/disk before I bring it to your attention. >>>> >>>> This run was not on an already provisioned device. I do see improved >>>> performance of the same volume after the first write. >>>> I understand this perf gain to be the overhead that is avoided during >>>> the subsequent run where no mappings need to be established. >>>> >>>> But, you mentioned zeroing of provisioned blocks as an issue. >>>> 1/ during lvcreate -Z from the man pages reports only controls the >>>> first 4K block. And also implies this is a MUST otherwise fs may hang. >>>> So, we are using this. Are you saying this controls zeroing of each >>>> chunk that's mapped to the thin volume? Yes - for 'lvcreate --type thin-pool' the option -Z controls 'zeroing' of thin-pool's thin volumes The bigger the chunks are, the bigger the impact of zeroing will be. >>>> >>>> 2/ The other about zeroing all the data chunks mapped to the thin >>>> volume, I could see only reference in the lvm.conf under >>>> thin_pool_zero, >>>> This is default enabled. So are you suggesting I disable this? If you don't need it - disable it - it's kind of more secure to have it enabled - but if you use 'filesystem' like ext4 on top - zeroing doesn't help as user of filesystem cannot read unwritten data. However if you read device as root - you might be able to read 'stale' data from unwritten parts of data from provisioned chunks. >>>> >>>> Please confirm the above items. I will come back with more precise >>>> details on the details you had requested for. >>>> As a side note - metadata device should preferabl sit on different spindle (SSD, nvme,...) as this is high-bandwith device and might frequently collide with your _tdata volume writes. Regrards Zdenek </blockquote></div>