Dear Mr. Kabelac, I am sorry for stealing your precious time. You are right, I could get the allocated blocks by the the text-output from thin_rmap. It is easier to recognize, if the output of thin_rmap changes (whenever at all?), than dealing direct with the metadata. Besides I like to * make experiments with things e.g. metadata. * have ideas on how to make something, and program it, e.g. backup program. I must admit, that "blk_archive" is more sophisticated than my things. Although 'blaming' me, you have helped me a lot. Sincerley Thomas =========================================================================== On Mon, November 18, 2024 10:28 am, Zdenek Kabelac wrote: > Dne 17. 11. 24 v 11:26 "Thomas Brücker" napsal(a): >> 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. > > > Hi > > > Of course you can always recreate the wheel as long as you have fun doing > that > - so yep you can full be inspired how to deal with 'thin-pool' metadata to > know which areas have some real data inside - although I'd probably > highly > recommend to stick with the use of original 'thin tools' - since those are > the > 'real tools' to work with thin-pool metadata - they know the format - they > are > regularly updated when format change and so on...   once you do you > 'copy' of > this rust code - you are loosing all those feature - IMHO not > worth.   (Note > - sooner or later there will be a new format of metadata...) > > > And if there are missing features in blk-archive - let's open the issue - > AFAIK this tool is still in development - so reasonable feature requests > will > be certainly implemented - you just need to write some good > examples/justifications how the feature should be working. > > > Regards > > Zdenek > > >> >> 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. > > > Is this some sort of  'raid1 + writemostly' ? > > And there is also another target -  'dm-era'  - which is however not > supported (yet) by lvm2...
