Extending "thin_trim"

Extending "thin_trim"

["Thomas Brücker"]

Hello developers and others,

Intro:
Lets consider a data device of an thin-provisioning combination. On it, some
data blocks are allocated ('by the metadata'), others not. (By using a thin-
provisioning combination, some data_blocks get allocated, then you write to
them, their content is probably not zero, and later, such a data_block is
disallocated.
"thin_trim" discards such unallocated data_blocks on the data device.

'Extending':
It would be fine, if "thin_trim" would have an option, that instead of
releasing
the blocks, "thin_trim" would write zeroes to these blocks.
--> REASON:
e.g.
* if you backup a data device by copying it to another device e.g. by
"dd", it
  would save time, when unallocated blocks are not copied, but just 'jumped'
  by seek (by specifying "conv=sparse" to dd) ("conv=sparse" does its job
  only, if these unallocated blocks are zeroed).

* I have an utility, that backups a data device clusterwise
  (cluster != data_block) to a cloud. To save space on the cloud, clusters
  which contain only zeroes, are not copied to the cloud. Here too, having
  a data device where every unallocated data_block is zero, would be fine.

Thank you for your generous device-mapper efforts.

Sincerely

Thomas Bruecker
Wydacker 43A
CH-3083 Trimtstein

Re: Extending "thin_trim"

[Zdenek Kabelac]

Dne 16. 11. 24 v 17:10 "Thomas Brücker" napsal(a):
> Hello developers and others,
>
> Intro:
> Lets consider a data device of an thin-provisioning combination. On it, some
> data blocks are allocated ('by the metadata'), others not. (By using a thin-
> provisioning combination, some data_blocks get allocated, then you write to
> them, their content is probably not zero, and later, such a data_block is
> disallocated.
> "thin_trim" discards such unallocated data_blocks on the data device.
>
> 'Extending':
> It would be fine, if "thin_trim" would have an option, that instead of
> releasing
> the blocks, "thin_trim" would write zeroes to these blocks.
> --> REASON:
> e.g.
> * if you backup a data device by copying it to another device e.g. by
> "dd", it
>    would save time, when unallocated blocks are not copied, but just 'jumped'
>    by seek (by specifying "conv=sparse" to dd) ("conv=sparse" does its job
>    only, if these unallocated blocks are zeroed).
>
> * I have an utility, that backups a data device clusterwise
>    (cluster != data_block) to a cloud. To save space on the cloud, clusters
>    which contain only zeroes, are not copied to the cloud. Here too, having
>    a data device where every unallocated data_block is zero, would be fine.
>
> Thank you for your generous device-mapper efforts.


Hi


I think you should pro probably examine this project: 
https://github.com/jthornber/blk-archive

IMHO zeroing would likely not be so good plan - i.e. imagine you have mostly 
empty 2TiB thinpool...

blk-archive solves this way more efficiently.


Regards


Zdenek