Re: badblocks

Roberto Fastec <roberto.fastec@xxxxxxxxx> · Mon, 22 May 2023 09:22:28 +0200

Wrong approach

Bad drives , cause ancient, are going to die so fast

Cloning them software will kill them faster that above

You should send the drive to a data recovery lab where they have Atola or  PC-3000 devices and will clone the drive in an hardware manner

Best solution I know is https://www.RecuperoDati299euro.it where they offer the cloning service (other labs will ask you a full recovery cost)

Hard drives should be used for the time the manufacturer offer as manufacturer' warranty, plus six months. Then you are using a "tyre" over 5 years old , you are not saving money, you are risking your life, since the tyres' rubber is has almost completely dried out.

Check out SMART, the drive will have not only reallocation events but also pending ones, which is the worse situation

Kind regards

R.
Il giorno 22 mag 2023, alle ore 08:59, graeme vetterlein <graeme.lvm@xxxxxxxxxxxxxx> ha scritto:

    This is my 1st post to this group.
    I'm not aware of anywhere I can search for "known
        issues" or similar ...short of opening each archive  and
        searching it.
    (happy to be corrected on this)

    I have a desktop Linux box (Debian Sid) with a clutch of disks in
      it (4 or 5)  and have mostly defined each disk as a volume group.

    Now a key point is some of the disks are NAS grade disks.
      This means they do NOT reallocate bad sectors silently. They
      report IO errors and leave it to the OS (i.e. the old fashion way
      of doing this)

    One of the disks (over 10 years old) had started reporting
      errors. I ran fsck with -cc but it never found the issue. In the
      end I bough a new disk and did:

      vgextend -- to add the new disk
      pvmove   -- move volumes off "bad" disk

      vgreduce -- remove bad disk from group

    While the pvmove is running I had plenty of time to think....

    The filesystem in the LV on the "bad disk" is now moving to the
      "new disk"  ...had the fsck managed to mark bad blocks, these
      would be in terms of the LV in which it sat and would be
      meaningless on  the new disk.

    Then the penny dropped! The only component that has a
      view on the real physical disk is lvm2 and in particular the PV
      ...so if anybody can mark(and avoid) badblocks it's the PV...so I
      should be looking for something akin to the -cc option of fsck ,
      applied to a PV command?

    Googling around I see lots of ill-informed comments by people
      who's never seen a read "bad block" and assume all modern disks
      solve this for you.

    --

    Graeme

linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/