All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Andreas Pflug <pgadmin@pse-consulting.de>
Subject: Re: [linux-lvm] Missing error handling in lv_snapshot_remove
Date: Wed, 07 Aug 2013 11:41:31 +0200	[thread overview]
Message-ID: <5202164B.5010302@redhat.com> (raw)
In-Reply-To: <520211BB.2040301@pse-consulting.de>

Dne 7.8.2013 11:22, Andreas Pflug napsal(a):
> Am 06.08.13 19:37, schrieb Bastian Blank:
>> Hi
>>
>> I tried to tackle a particular bug that shows up in Debian for some time
>> now. Some blamed the udev rules and I still can't completely rule them
>> out. But this triggers a much worse bug in the error cleanup of the
>> snapshot remove. I reproduced this with Debian/Linux 3.2.46/LVM 2.02.99
>> without udevd running and Fedora 19/LVM 2.02.98-10.fc19.
>>
>> On snapshot removal, LVM first converts the device into a regular LV
>> (lv_remove_snapshot) and in a second step removes this LV
>> (lv_remove_single). Is there a reason for this two step removal? An
>> error during removal leaves a non-snapshot LV behind.
> Ah, this explains why sometimes my backup stops: I take a snapshot,
> rsync the stuff and remove the snapshot with a daily cron job, but I
> observed twice that a non-snapshot volume named like a backup snapshot
> was lingering around, preventing the script to work. So this is no
> exotic corner case, but happens in real life.
>
> I observe this since I dist-upgraded to wheezy.
>

Because Debian is using non-upstream udev rules.

With upstream udev rules with standard real-life use, this situation
cannot happen - since these rules are constructed to play better with
udev WATCH rule.

Zdenek

  reply	other threads:[~2013-08-07  9:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-06 17:37 [linux-lvm] Missing error handling in lv_snapshot_remove Bastian Blank
2013-08-07  9:13 ` Zdenek Kabelac
2013-08-07 12:36   ` Bastian Blank
2013-08-07 13:32     ` Alasdair G Kergon
2013-08-07 15:13     ` Zdenek Kabelac
2013-08-08 13:33   ` Ritesh Raj Sarraf
2013-08-09  9:50     ` Zdenek Kabelac
2013-08-07  9:22 ` Andreas Pflug
2013-08-07  9:41   ` Zdenek Kabelac [this message]
2013-08-07 17:18     ` Andreas Pflug
2013-08-08 10:01       ` Zdenek Kabelac
2013-08-09  7:57         ` Andreas Pflug
2013-08-09  9:40           ` Zdenek Kabelac

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5202164B.5010302@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=pgadmin@pse-consulting.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.