All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Christian Hesse <list@eworm.de>, Peter Rajnoha <prajnoha@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] blkid_wiping breaks snapshots
Date: Mon, 10 Feb 2014 16:56:45 +0100	[thread overview]
Message-ID: <52F8F6BD.6000101@redhat.com> (raw)
In-Reply-To: <20140210153707.261afa77@leda.localdomain>

Dne 10.2.2014 15:37, Christian Hesse napsal(a):
> Peter Rajnoha <prajnoha@redhat.com> on Mon, 2014/02/10 15:12:
>> On 02/10/2014 02:48 PM, Christian Hesse wrote:
>>> Zdenek Kabelac <zkabelac@redhat.com> on Mon, 2014/02/10 13:20:
>>>> Dne 10.2.2014 10:30, Christian Hesse napsal(a):
>>>>> Zdenek Kabelac <zkabelac@redhat.com> on Mon, 2014/02/10 09:33:
>>>>>> Dne 8.2.2014 00:55, Christian Hesse napsal(a):
>>>>>>> Christian Hesse <list@eworm.de> on Sat, 2014/02/08 00:36:
>>>>>>>> Hello everybody,
>>>>>>>>
>>>>>>>> I think I nailed it down with git bisect. My first bad commit is:
>>>>>>>>
>>>>>>>> 75628f341ad38b68aae33eae0b5700be2a6e5769
>>>>>>>> configure: enable blkid_wiping by default if the blkid library is
>>>>>>>> present
>>>>>>>>
>>>>>>>> Looks like this wipes data that is still needed... Building a package
>>>>>>>> with '--disable-blkid_wipe' now to verify on another system.
>>>>>>>
>>>>>>> Uh, this only helps part of...
>>>>>>>
>>>>>>> I changed my test setup and used writable snapshots. After that I got:
>>>>>>>
>>>>>>> WARNING: DM_snapshot_cow signature detected on /dev/cvg/snap-home at
>>>>>>> offset 0. Wipe it? [y/n]
>>>>>>>
>>>>>>> (see https://bbs.archlinux.org/viewtopic.php?id=176504 for another
>>>>>>> report)
>>>>>>>
>>>>>>> Looks like disabling blkid_wiping fixes this. My snapshot corruption
>>>>>>> still occurs though. :-/
>>>>>>> Bad thing about it is that the corruption does not occur reliable when
>>>>>>> doing simple tests in 'git bisect'... Out of ideas for now - Will go
>>>>>>> to bed now.
>>>>>>
>>>>>> Now this was helpful, I guess I think what is going on.
>>>>>
>>>>> Great! Waiting for patches then. :D
>>>>>
>>>>> I could provide some more information when needed:
>>>>>
>>>>> * This happens with read only snapshots only.
>>>>> * I could reproduce with commit eaa23d32732c9bc3dd4f948781b5764cf21d84ba
>>>>>     (wiping: add support for blkid wiping), so it was introduced there or
>>>>>     before.
>>>>>
>>>>> Should I investigate further or wait for something to test from you?
>>>>
>>>> Is the patch bellow fixing your problem ?
>>>> (It's still not final - but should help)
>>>>
>>>> Zdenek
>>>>
>>>>
>>>> diff --git a/tools/lvcreate.c b/tools/lvcreate.c
>>>> index 638a868..e8b1a7f 100644
>>>> --- a/tools/lvcreate.c
>>>> +++ b/tools/lvcreate.c
>>>> @@ -772,7 +772,7 @@ static int _read_activation_params(struct
>>>> lvcreate_params *lp, LVM_READ | LVM_WRITE);
>>>>
>>>>           /* Must not zero/wipe read only volume */
>>>> -       if (!(lp->permission & LVM_WRITE)) {
>>>> +       if (!lp->snapshot && !(lp->permission & LVM_WRITE)) {
>>>>                   lp->zero = 0;
>>>>                   lp->wipe_signatures = 0;
>>>>           }
>>>
>>> This looks good to me. I've made some backups now without any corruption.
>>>
>>> But with blkid_wiping enabled I do have this warning/question now for read
>>> only snapshots as well:
>>>
>>> WARNING: DM_snapshot_cow signature detected on /dev/cvg/snap-home
>>> at offset 0. Wipe it? [y/n]
>>>
>>> lvm works perfectly only with your patch applied and compiled with
>>> --disable-blkid_wiping.
>>
>> Also, try this patch in addition:
>>
>> https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=ed166a3b1d3290ad887d8f83c24a8d8877713d3c
>
> That did the trick. Thanks a lot!
>
> If anybody is interested... These are the patches updated to apply against
> version 2.02.105:
>
> http://www.eworm.de/download/linux/lvm2-snapshot.patch
> http://www.eworm.de/download/linux/lvm2-snapshot-wiping.patch
>


We need to resolve the logic behind the query for wiping. We will most 
probably go with this logic:

We query for wipe of 'known' signatures, before passing newly allocated 
'normal' LV (visible).
Any other so called 'private/hidden' LV will do either wipe or unconditional 
zeroing of 1st. 4kb - which is usually the only thing needed here.

Current logic is somewhat overcomplicated.

Zdenek

  reply	other threads:[~2014-02-10 15:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 13:27 [linux-lvm] lvm2 2.02.105 breaks snapshots Christian Hesse
2014-02-04  8:55 ` Christian Hesse
2014-02-04 16:47   ` Zdenek Kabelac
2014-02-06 14:48     ` Christian Hesse
2014-02-07 13:14     ` Christian Hesse
2014-02-07 23:36       ` [linux-lvm] blkid_wiping breaks snapshots (was: lvm2 2.02.105 breaks snapshots) Christian Hesse
2014-02-07 23:55         ` Christian Hesse
2014-02-10  8:33           ` [linux-lvm] blkid_wiping breaks snapshots Zdenek Kabelac
2014-02-10  9:30             ` Christian Hesse
2014-02-10 12:20               ` Zdenek Kabelac
2014-02-10 13:48                 ` Christian Hesse
2014-02-10 14:12                   ` Peter Rajnoha
2014-02-10 14:37                     ` Christian Hesse
2014-02-10 15:56                       ` Zdenek Kabelac [this message]
2014-02-10 18:15                         ` Peter Rajnoha
2014-02-10 19:50                           ` Zdenek Kabelac
2014-02-18  8:15                   ` Christian Hesse
2014-02-18  8:27                     ` 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=52F8F6BD.6000101@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=list@eworm.de \
    --cc=prajnoha@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 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.