[dm-devel] dm thin pool discarding

Zdenek Kabelac zkabelac at redhat.com
Thu Jan 10 15:55:04 UTC 2019


Dne 10. 01. 19 v 16:23 Martin Wilck napsal(a):
> On Thu, 2019-01-10 at 16:08 +0100, Zdenek Kabelac wrote:
>> Dne 10. 01. 19 v 14:41 Martin Wilck napsal(a):
>>>
>>> I for one would find it very attractive if dm-thin had a mode
>>> supporting fast zeroout.
>>
>> I believe '/sys/block/*/queue/discard_zeroes_data  is now always
>> returning
>> false for any device as it's been considered as unreliable logic.
>>
>> So using 'discard' for zeroing is not really an option here.
> 
> True. But we have "write_zeroes_max_bytes" instead. In device mapper
> terms, it's "num_write_zeroes_bios", which isn't set for dm-thin. With
> the logic outlined above, it could be set, AFAICT.


I assume this is valid request for enhancement of thin-pool target.
However  this  'WRITE_SAME'  or whatever scsi low-level command is that is 
basically targeted for thinLV user.

So in this case the most effective 'zeroing' of thinLV areas is its discard.

It'd be interface abuse to use it for intentional slow physical 'zeroing' of 
allocated chunks before they are 'returned' to the pool.

On the other hand I can imagine some sort of 'new' flag - that would always 
zero chunks that are returned to the thin-pool - or it could be a message send 
before final release of thinLV.

So in that case - you would send a dm message 'SECURE_ERASE'  (or if there is 
some common interface for that) before actual lvremove call and thin-pool 
would zero out all exclusively provisioned blocks that would be returned back 
to pool.

I guess you can formulate something like this as RFE BZ.

Also note - you can do this operation yourself already today by using 
thin-tool and using some scripting-fu skills - but it's pretty hacky....


Zdenek




More information about the dm-devel mailing list