[linux-lvm] lvm Bug? - bad reaction to snapshot creation

[Leeman Strout]

On 06/10/2014 03:58 AM, Zdenek Kabelac wrote:
> Dne 9.6.2014 16:53, Leeman Strout napsal(a):
>> On 06/09/2014 05:50 AM, Zdenek Kabelac wrote:
>>> Dne 7.6.2014 01:26, Leeman Strout napsal(a):
>>> Hi
>>>
>>> Unsure if this relates to all your problem (since I'm not sure how
>>> arch linux is in sync with udev rules & systemd version)
>>>
>>> At certain moment systemd added a new 'feature' about locking
>>> devices while updating internal udev state - this locking ignores any
>>> udev rule flags and opens internal lvm2 devices - so while for now
>>> it's been again disabled for 'dm' devices - you might have installed
>>> version of system which has the 'lock everything' feature in?
>> systemd 213-6 is what Arch reports, as far as I can tell from the
>> PKGBUILD
>> it's vanilla 213 plus 2 patches:
>> - backport fix for faily MACAddress matching (FS#40675)
>> - backport fix for fsck/udev mess (FS#40706)
>
>
> this commit should be fixing problems for lvm2 & latest systemd:
>
> e918a1b5a94f270186dca59156354acd2a596494
>
> and this is systemd commit which has introduced problem:
>
> 3d06f4183470d42361303086ed9dedd29c0ffc1b
>
> Unsure what do you have in your arch build.
>
>>> Thought this doesn't explain your 'counter below zero' error - this
>>> looks like some incorrect udev rules are running in the field ? (Or
>>> maybe multiple systemd-udevd are running ?)
>> After a clean restart of everything twice without doing snapshots, the
>> initial
>> lvcreate does not have the 'counter below zero' error.  And with special
>> attention to make sure the snapshots are cleaned up prior to
>> attempting a new
>> snapshot I am not getting this initial decrement on lvcreate.
>
> So could we consider this  'counter' case is solved ?
>
> Zdenek
>


Am testing the rev Arch dev pushed w/ that change : 
https://projects.archlinux.org/svntogit/packages.git/diff/trunk/0001-udev-exclude-device-mapper-from-block-device-ownersh.patch?h=packages/systemd&id=331c26905843338b30b4cd240c64953501cd879c

It does not resolve the issue.


Thanks,
Leeman