From: Bastian Blank <waldi@debian.org>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Missing error handling in lv_snapshot_remove
Date: Wed, 7 Aug 2013 14:36:57 +0200 [thread overview]
Message-ID: <20130807123656.GA18854@mail.waldi.eu.org> (raw)
In-Reply-To: <52020FD1.2000004@redhat.com>
On Wed, Aug 07, 2013 at 11:13:53AM +0200, Zdenek Kabelac wrote:
> Dne 6.8.2013 19:37, Bastian Blank napsal(a):
> >I hold the cow device open so it will run into the error condition:
> >| $ sleep 100 < /dev/mapper/vg-test_snap-cow&
> You are breaking the lvm2 logic thus pushing the code to go through
> unexpected error code path - user is never supposed to open so
> called 'private' /dev/mapper/ devices.
I'm a developer and use it to trigger an error condition. Please don't
start with that crap about what a user should or should not do.
> >Then try to remove the LV:
> >| $ lvremove vg/test_snap
> With upstream lvm2 code - there is embedded 'retry' loop - so the removal
> should be retried for couple times (controllable by lvm.conf).
Please show that it actually does anything in this case. This is no
condition that goes away, but a logic bug.
> That's because udev WATCH rule might be fired basically anytime
> after close of device opened in write mode - so it may happen lvm2
> checks device is not opened and could be removed, but the udev WATCH
> rules opens temporarily device and lvm2 then fails to remove device,
> which has been previously detected as unused.
There is not udevd running! Please explain how udev can be a problem in
this case.
> There has been bug affecting cluster usage of exclusive snapshots in
> pre .99 version - the order of taking locks for devices was not
> correct, and if there
> has been clvmd restart during snapshot - it has caused some problems.
Did you actually read the code? At least I can clearly see that the
error logic is broken.
> But for current (.99) code - in normal case the operation should
> work properly. For any unpredictable errors - lvm2 command should
> print error message and it's up-to admin to fix dangling device and
> table entries.
It is up to LVM to not break the system with suspended devices.
Bastian
--
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9
next prev parent reply other threads:[~2013-08-07 12:37 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 [this message]
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
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=20130807123656.GA18854@mail.waldi.eu.org \
--to=waldi@debian.org \
--cc=linux-lvm@redhat.com \
/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 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).