Hello developers and others,
I agree fully with your '2TB-argument'. So no longer zeroing.
I have taken a closer look to "blk-archive". "Packing to a remote archive"
there not yet works. I have an ((alpha ** n); n --> infinity)-solution of
my own, which can do this (it is accessible as an nbd device).
Furthermore I sometimes really need to copy the data device to another
location (see crazy-rationale, if you want).
Somehow I like modularity, leading to "<progr. a> | <progr. b> | ... " (here
"<...>" means a variable to be set).
(In further text, "data device" means solely a data device of a thin pool.)
Whats with / (I prefer to develop) an utility similar to "dd" (stealing code
from "dd" and "blk-archive" [I hope its all "GPL" or similar]), which skips
unallocated blocks either on a thin device(got idea from "blk-archive") or a
data device.
Sincerely
Thomas Bruecker
PS:
crazy rationale (to be skipped):
* My name: "pseudo-raid": raid5 with legs on the same device, especially a
hard disk. Ok, I admit, its slow.
* Reason:
* Modern hard disks are able to correct defective sectors, if the driver
knows, what should be in these sectors.
* You may not equip a notebook with additional hard disk.
* I have an (experimental) server lacking of slots for additional hard disks.
I just needed more disk space there, and was just able to insert one
additio-
nal disk.
I intended to use this diskd for experimental purpose (--> no important
data).
I just had (and wanted to use) a hard disk with defective sectors
(<-- "smartclt"), no longer using this disk in a serious production
environment.
I put a "pseudo-raid" on this disk (to protect 'me' from further emerging
defective sectors).
On the "pseudo-raid", I installed a thin-provisioning-device combination
(data, metadata).
Years passed by.
Then I had to migrate a server from one location to a not yet existing
other location. So I temporarely stored the server on THIS experimental
disk, running it on the experimental server.
It should have been for some weeks, ev. months.
Years passed by (in german we say "Providurium" aka. Provisorium).
Then suddenly another hard disk, also with defective sectors, crashed
(finally no longer beeing able to start the disk).
I though Oh, what is with my 'semi-'defective hard disk with the server on
it, if it crashes ... .
To copy an about 450G data device (maybe nearly empty) to another location
by "dd" ...
So I 'put a raid1 on the "pseudo raid"' (one leg "pseudo-raid", other leg
a [well working] hard disk).
Things work slower and slower ... .
Actually I should renovate the whole combination to a simple raid<n>,
but copying the data device by "dd" ...
A "dd" that skips unallocated blocks would really be fine.
===============================================================================
On Sat, November 16, 2024 8:41 pm, Zdenek Kabelac wrote:
> Dne 16. 11. 24 v 17:10 "Thomas Bruecker" napsal(a):
>> Hello developers and others,
>>
>> ['extending "thin_trim", so that it zeroes unallocated blocks.'] [...]
>> [...]
>>
>>Sincerely
>>
>>Thomas Bruecker
>>Wydacker 43A
>>CH-3083 Trimtstein
>
> 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
