Re: (Re * Re): Extending "thin_trim"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...







[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux