Re: thin: pool target too small

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 23, 2020 at 2:49 PM Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
>
> Dne 23. 09. 20 v 20:13 Duncan Townsend napsal(a):
> > On Tue, Sep 22, 2020, 5:02 PM Zdenek Kabelac <zkabelac@xxxxxxxxxx
> >
> > dmeventd does write its PID file into the correct directory in the
> > post-initramfs root, so whatever's happening is some weird hybrid. I'll debug
> > this further with my distro.
> >
> >     So I think to prevent repeated occurrence of this problem - you'll need
> >     to ensure your system-booting will follow the pattern from distros
> >     like Fedora.
> >
> >
> > I think for now, the easiest solution may be to try to stop dmeventd from
> > being started by dracut.
>
> Basically all you need to do for dracut (with reagards to dmeventd) is to
> setup inside dracut environemnt  'monitoring=0'  in /etc/lvm/lvm.conf there.
> (so when it's copied system's lvm.conf there - replace with sed/awk...)
>
> Also there is   'metadata_read_only=1' setting that can be useful for
> dracut environment.

Thanks for the advice!

> Dracut needs some bigger fixing on its own - but ATM we simply can't
> provide set of features we would like to have.
>
> > I have encountered a further problem in the process of restoring my thin pool
> > to a working state. After using vgcfgrestore to fix the mismatching metadata
> > using the file Zdenek kindly provided privately, when I try to activate my
> > thin LVs, I'm now getting the error message:
> >
> > Thin pool <THIN POOL LONG NAME>-tpool transaction_id (MAJOR:MINOR)
> > transaction_id is XXX, while expected YYY.
> Set the transaction_id to the right number in the ASCII lvm2 metadata file.

I apologize, but I am back with a related, similar problem. After
editing the metadata file and replacing the transaction number, my
system became serviceable again. After making absolutely sure that
dmeventd was running correctly, my next order of business was to
finish backing up before any other tragedy happens. Unfortunately,
taking a snapshot as part of the backup process has once again brought
my system to its knees. The first error message I saw was:

  WARNING: Sum of all thin volume sizes (XXX TiB) exceeds the size of
thin pool <VG>/<THIN POOL LV> and the size of whole volume group (YYY
TiB).
  device-mapper: message ioctl on  (MAJOR:MINOR) failed: File exists
  Failed to process thin pool message "create_snap 11 4".
  Failed to suspend thin snapshot origin <VG>/<THIN LV>.
  Internal error: Writing metadata in critical section.
  Releasing activation in critical section.
  libdevmapper exiting with 1 device(s) still suspended.

There were further error messages as further snapshots were attempted,
but I was unable to capture them as my system went down. Upon reboot,
the "transaction_id" message that I referred to in my previous message
was repeated (but with increased transaction IDs).

I will reply privately with my lvm metadata archive and with my
header. My profuse thanks, again, for assisting me getting my system
back up and running.
--Duncan Townsend

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




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux