From: Nicholas Geovanis <firstname.lastname@example.org>
To: LVM general discussion and development <email@example.com>
Subject: Re: [linux-lvm] Cannot manage FS of thin volume
Date: Mon, 28 Feb 2022 12:22:33 -0600 [thread overview]
Message-ID: <CAJmb-YmNfid-AwSkACu8D7pT_27yCPtCLa2wiCnEEZk-xqo2pA@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3579 bytes --]
On Mon, Feb 28, 2022, 12:26 AM Viktor Trojanovic <firstname.lastname@example.org> wrote:
> Hi there,
> I seem to have some problems involving my LVM setup and hope I can get
> some advice on this list.
> I have a rather simple setup. One PV (on a RAID1-MD-Device), one VG, 3 LVs
> and one thin pool that holds my Linux Containers (LXD). These container
> volumes are created directly by LXD.
> Yesterday, I noticed that my backups are no longer working. In order to
> backup the containers, I used to do the following:
> 1. Make a snapshot of the container using LXD. This creates a LV snapshot.
> 2. Mount the snapshot.
> 3. Use the mount for backing up all files
> 4. Unmount, delete snapshot.
> I remember this used to work fine. So I tried doing this step by step and
> already failed at the second step. I could not mount the snapshot because
> it never got even created as a device in /dev/mapper.
There may be a similar issue mentioned on discuss.linuxcontainers.org.
It seems to be caused by incorrectly specified device size on the "lxc
config device" command. You can use "GB" or "GiB" for size.
But you can't use "G", and you don't find out.
I thought that maybe something changed in LXD and that I had to forcefully
> activate the snapshot. I then tried something with the -Ky flag but nothing
> really worked. And after I rebooted the server, all of a sudden all volumes
> were inactive.
> With the help of a couple of internet guides, in particular this one: LVM
> Transaction ID mismatch and metadata resize error – Monotok
> I managed to get everything working again. So the system is booting fine,
> the containers too. I can even mount the containers fine.
> But something is still very wrong. For example, I tried to resize one of
> the thin LVs from 10G to 20G with automatic resizing of the FS. While the
> LV resizing seems to have worked fine, the FSresize did not.
> This is how it looks when I try to run resize2fs on one of the containers
> # resize2fs /dev/vg0/containers_cont1
> resize2fs 1.44.1 (24-Mar-2018)
> resize2fs: Device or resource busy while trying to open
> Couldn't find valid filesystem superblock.
> Here's the output of running fdisk on the volume
> # fdisk /dev/mapper/vg0-containers_cont
> Welcome to fdisk (util-linux 2.31.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
> The old ext4 signature will be removed by a write command.
> Device does not contain a recognized partition table.
> Created a new DOS disklabel with disk identifier 0x174c0f1c.
> It clearly looks like something is wrong. One of the steps I had to take
> when following the guide mentioned above is to backup the vg and change the
> id of the thin pool to another value. Maybe this messed up something else.
> Though I am confused that things overall seem to work. lsblk -f recognizes
> the filesystem in the thin volumes, I can mount them, I can work with them.
> But I cannot resize them and I cannot seem to create snapshots
> successfully. If I do and mount them, they are empty.
> Any pointers would be much appreciated.
> linux-lvm mailing list
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[-- Attachment #1.2: Type: text/html, Size: 4979 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
linux-lvm mailing list
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
prev parent reply other threads:[~2022-03-01 7:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-27 15:17 [linux-lvm] Cannot manage FS of thin volume Viktor Trojanovic
2022-02-28 18:22 ` Nicholas Geovanis [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).