[linux-lvm] bug? shrink lv by specifying pv extent to be removed does not behave as expected

[Roberto Fastec]

Zdenek is right

But if in this exact moment one or more drive do have not only bad sectors "reallocated" but also "pending" ones 

the best choice is to preserve them shutting them off and allowing a PRO cloning process with machines like PC-3000

But first at a PRO lab, they will open the drive in clean room for the sake of check and verify WHY SMART are so bad for such amount of sectors

If recovering the data is a must, failing the preservation of the bad SMART drives , will result in loosing them and together the data too.

Read on the data recovery guide published on the website of the told company

R.

⁣ ​

Il giorno 12 apr 2023, 12:20, alle ore 12:20, Zdenek Kabelac <zdenek.kabelac at gmail.com> ha scritto:
>Dne 09. 04. 23 v 20:21 Roland napsal(a):
>>> Well, if the LV is being used for anything real, then I don't know
>of
>>> anything where you could remove a block in the middle and still have
>a
>>> working fs.   You can only reduce fs'es (the ones that you can
>reduce)
>> 
>> my plan is to scan a disk for usable sectors and map the logical
>volume
>> around the broken sectors.
>> 
>> whenever more sectors get broken, i'd like to remove the broken ones
>to have
>> a usable lv without broken sectors.
>>
>
>Reall silly plan  - been there years back in time when drives were FAR
>more 
>expensive with the price per GiB.
>
>Todays - just throw bad drive to recycle bin - it's not worth to do
>this 
>silliness.
>
>HDD bad sectors are spreading - and slowly the surface gets
>destroyed....
>
>So if you make large 'head-room' around bad disk areas - if they are 
>concentrated on some disk area - and you know topology of you disk
>drive
>like i.e. 1% free disk space before and after bad area - you could
>possibly 
>use disk for a little while more - but only to store invaluable
>data....
>
>
>> since you need to rebuild your data anyway for that disk, you can
>also
>> recreate the whole logical volume.
>> 
>> my question and my project is a little bit academic. i'd simply want
>to try
>> out how much use you can have from some dead disks which are trash
>otherwise...
>
>You could always take  'vgcfgbackup'  of lvm2 metadata and make some
>crazy 
>transition of if with even  AWK/python/perl   -  but we really tend to
>support
>just some useful features - as there is already  'too much' and users
>are 
>getting often lost.
>
>One very simply & naive implementation could be going alonge this path
>-
>
>whenever you want to create new arrangement for you disk with 'bad'
>areas,
>you can always start from 'scratch' - since afterall - lvm2 ONLY
>manipulates 
>with metadata within disk front - so if you need to create new 'holes',
>just   'pvcreate -f', vgcreate,   and 'lvcreate -Zn -Wn'
>and then  'lvextend'  with normal  or  'lvextend --type error | --type
>zero' 
>segment types around bad areas with specific size.
>Once you are finished and your LV precisely matches your 'previous'  LV
>of you 
>past VG - you can start to use this LV again with new arrangement of 
>'broken 
>zeroed/errored' areas.
>
>I've some serious doubts about usability of this with any filesystem :)
>but if 
>you think this has some added value - fell free to use.
>If the drive you play with would be 'discardable' (SSD/NVMe) then one
>must 
>take extra care there is no 'discard/TRIM' anywhere in the process - as
>that 
>would lose all data irrecoverably....
>
>But good advice from me - whenever  'smartctl' starts to show
>relocation block 
>errors - it's the right moment to  'dd_rescue' any LV to your new
>drive...
>> 
>> yes, pvmove is the other approach for that.
>> 
>> but will pvmove continue/finish by all means when moving extents
>located on a
>> bad sector ?
>
>pvmove  CANNOT be used with bad drives - it cannot deal with erroring
>sectors 
>and basically gets stuck there trying to mirror unrecoverable disk
>areas...
>
>Regards
>
>Zdenek
>
>
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm at redhat.com
>https://listman.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20230412/0873c670/attachment-0001.htm>