On 13-04-02 07:51 AM, Marian Csontos wrote:
>
> You said there is a LV containing the bad block. You can not have a
> block belonging to two LVs
Ah ha! The missing link. Interestingly enough, as I was going through
this process I had a nagging feeling that I somehow needed to release
the block from the existing LV.
> Use something like `pvmove --alloc anywhere /dev/sda2:2812` first.
Yeah. That did the trick.
> I fully respect your choice, I myself have enough of throw away data
> like VMs...
Thanks.
> Just for convenience, if you can spare more than 2 blocks be more
> generous and disable larger extent of blocks - those disk errors like to
> spread... (or allocate to LV which loosing will be least )
Yeah. I don't mind handling them piecemeal. Like I said, nothing on
this machine is irreplaceable.
> Sometimes backups are not backups. To check if the backups work, have
> you ever tried to recover *all* data from those backups?
But of course! You can't really call it a backup unless you have done a
successful restore. I had to restore a machine from this same backup
only a few weeks ago.
> By size of the disk looks like notebook.
Nope. Just old enough that that size disk was "common" when it was built.
> Are you using disk encryption?
Nope.
> (Loosing LUKS header could be rather painful!
Indeed. But not encrypting. In any case, losing the LUKS header might
be just enough excuse to restore to bare-metal.
> And also depending on FS you may loose more than just few files.
Yeah. Pass on XFS and Reiserfs. Both have lost me too much data to use
again. Fortunately ext{3,4} don't have such catastrophic failures just
losing a block or two.
Cheers,
b.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
