[linux-lvm] Insufficient free space: 1 extents needed, but only 0 available with 32.83g available

[linux-lvm] Insufficient free space: 1 extents needed, but only 0 available with 32.83g available

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

I have a VG:

  VG          #PV #LV #SN Attr   VSize   VFree 
  rootvol_tmp   1  26   0 wz--n-  74.40g 32.83g

Which has an LV in it which has a bad disk block on it.  Per previous
discussions here I have an LV into which I can remap PEs with bad blocks on them:

# lvdisplay --maps /dev/rootvol_tmp/badblocks
  --- Logical volume ---
  LV Name                /dev/rootvol_tmp/badblocks
  VG Name                rootvol_tmp
  LV UUID                oRCTFY-XNxh-3FA5-8lUG-FsOG-GjaO-giAcIu
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                4.00 MiB
  Current LE             1
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2
   
  --- Segments ---
  Logical extent 0 to 0:
    Type		linear
    Physical volume	/dev/sda2
    Physical extents	2805 to 2805

As you can see, it has a PE in it already.  I am trying to map another
PE into it but getting an error:

# lvextend --alloc anywhere /dev/rootvol_tmp/badblocks -l +1 /dev/sda2:2812
  Extending logical volume badblocks to 8.00 MiB
  Insufficient free space: 1 extents needed, but only 0 available

Clearly there is something wrong with my syntax but I'm not quite sure
what it is.  Any ideas?

Much thanks!

b.

P.S. Please, no lectures about replacing the disk.  I understand the risks
of operating on a disk that is starting to show signs of wear.  All of
the data on this disk is backed up twice daily and anything lost
between those backups will not be missed.  It's just not feasible for me
to replace this disk at this time.  Thanks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [linux-lvm] Insufficient free space: 1 extents needed, but only 0 available with 32.83g available

[Marian Csontos]

On 04/01/2013 02:23 PM, Brian J. Murrell wrote:
> I have a VG:
>
>    VG          #PV #LV #SN Attr   VSize   VFree
>    rootvol_tmp   1  26   0 wz--n-  74.40g 32.83g
>
> Which has an LV in it which has a bad disk block on it.  Per previous
> discussions here I have an LV into which I can remap PEs with bad blocks on them:
>
> # lvdisplay --maps /dev/rootvol_tmp/badblocks
>    --- Logical volume ---
>    LV Name                /dev/rootvol_tmp/badblocks
>    VG Name                rootvol_tmp
>    LV UUID                oRCTFY-XNxh-3FA5-8lUG-FsOG-GjaO-giAcIu
>    LV Write Access        read/write
>    LV Status              available
>    # open                 0
>    LV Size                4.00 MiB
>    Current LE             1
>    Segments               1
>    Allocation             inherit
>    Read ahead sectors     auto
>    - currently set to     256
>    Block device           252:2
>
>    --- Segments ---
>    Logical extent 0 to 0:
>      Type		linear
>      Physical volume	/dev/sda2
>      Physical extents	2805 to 2805
>
> As you can see, it has a PE in it already.  I am trying to map another
> PE into it but getting an error:
>
> # lvextend --alloc anywhere /dev/rootvol_tmp/badblocks -l +1 /dev/sda2:2812
>    Extending logical volume badblocks to 8.00 MiB
>    Insufficient free space: 1 extents needed, but only 0 available

>
> Clearly there is something wrong with my syntax but I'm not quite sure
> what it is.  Any ideas?

You said there is a LV containing the bad block. You can not have a 
block belonging to two LVs (for completeness sake: it is possible in 
snapshots but those shared extents can not be created like that ^)

*Is the extent 2812 free?*

*No*
Use something like `pvmove --alloc anywhere /dev/sda2:2812` first.

Known issues: it does not work on mirrors and snapshots.
Workarounds? Split the mirror. Delete snapshot. Or you could try to 
hand-edit the metadata.

Also I am unsure what's the granularity of data it would skip - you may 
try to extract them first with e.g. ddrescue.

*Yes*
Then I have no idea except you may try specifying range /dev/sda2:2812-2812

>
> Much thanks!
>
> b.
>
> P.S. Please, no lectures about replacing the disk.  I understand the risks
> of operating on a disk that is starting to show signs of wear.  All of
> the data on this disk is backed up twice daily and anything lost
> between those backups will not be missed.  It's just not feasible for me
> to replace this disk at this time.  Thanks.

I fully respect your choice, I myself have enough of throw away data 
like VMs...

Except you may want to consider following:

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 )

Sometimes backups are not backups. To check if the backups work, have 
you ever tried to recover *all* data from those backups?

By size of the disk looks like notebook. Are you using disk encryption? 
(Loosing LUKS header could be rather painful! Have you backed up that as 
well? Otherwise you would need to restore everything - which may be 
impractical for example over slow network or with limited data.)

Similar applies to loosing LVM metadata.

And also depending on FS you may loose more than just few files.

-- Marian


>
>
>
> _______________________________________________
> 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/
>

Re: [linux-lvm] Insufficient free space: 1 extents needed, but only 0 available with 32.83g available

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]