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

2023-04-13 Thread Roberto Fastec
"but shouldn't we perhaps leave it up to the end user / owner of the hardware,  to decide when it's ready for the recycle bin ?" with hard drives (forget SSDs, they are hardware accelerators absolutely unaffordable for data storing) it is not the user/owner that decide it , unless he doesn't

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

2023-04-13 Thread Roberto Fastec
P.S. needless to be said, that they eventually can reassemble damaged LVM , until LVM's metadata tables are still good enough Il giorno 12 apr 2023, 08:39, alle ore 08:39, Roland ha scritto: > >Controllers remap blocks all on their own and the so-called geometry >is entirely fictitious anyway

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

2023-04-13 Thread 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

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

2023-04-13 Thread Roberto Fastec
If you are in trouble with the disks set because of bad healthiness of the drives they helped me with really convenient fee-per-disk in Verona , Italy It is the most well reputate (checked and compared with Google reviews) data recovery lab in Italy. If you want the reference, just drop me an

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

2023-04-12 Thread Zdenek Kabelac
Dne 12. 04. 23 v 14:37 Roland napsal(a): >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. ok, i understand your point of view. and thank you for

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

2023-04-12 Thread Roland
>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. ok, i understand your point of view. and thank you for the input. but this applies to a world with

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

2023-04-12 Thread Zdenek Kabelac
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

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

2023-04-12 Thread Roland
>Controllers remap blocks all on their own and the so-called geometry is entirely fictitious anyway so tell me then, why i have a shelf full with dead disks where half of them are out of business for nothing but a couple of bad sectors ? i don't see the point that hardware capable storing

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

2023-04-11 Thread Roger Heflin
On Tue, Apr 11, 2023 at 1:44 AM matthew patton wrote: > > > my plan is to scan a disk for usable sectors and map the logical volume > > around the broken sectors. > > 1977 called, they'd like their non-self-correcting HD controller > implementations back. > > From a real-world perspective there

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

2023-04-11 Thread matthew patton
> my plan is to scan a disk for usable sectors and map the logical volume>  >around the broken sectors. 1977 called, they'd like their non-self-correcting HD controller implementations back. >From a real-world perspective there is ZERO (more like negative) utility to >this exercise. Controllers

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

2023-04-09 Thread Stuart D Gathman
I use a utility that maps bad sectors to files, then move/rename the files into a bad blocks folder. (Yes, this doesn't work when critical areas are affected.) If you simply remove the files, then modern disks will internally remap the sectors when they are written again - but the quality of

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

2023-04-09 Thread Roland
thank you, very valuable! Am 09.04.23 um 20:53 schrieb Roger Heflin: On Sun, Apr 9, 2023 at 1:21 PM Roland wrote: 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

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

2023-04-09 Thread Roger Heflin
On Sun, Apr 9, 2023 at 1:21 PM Roland wrote: > > > 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) > > by reducing off of the

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

2023-04-09 Thread Roland
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) by reducing off of the end and making it smaller. yes, that's clear to me. It

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

2023-04-09 Thread Roger Heflin
On Sun, Apr 9, 2023 at 10:18 AM Roland wrote: > > hi, > > we can extend a logical volume by arbitrary pv extends like this : > > > root@s740:~# lvresize mytestVG/blocks_allocated -l +1 /dev/sdb:5 >Size of logical volume mytestVG/blocks_allocated changed from 1.00 > MiB (1 extents) to 2.00 MiB