[systemd-devel] [ANNOUNCE] systemd 214

[Kay Sievers]

On Wed, Jun 11, 2014 at 8:49 PM, Alexander E. Patrakov
<patrakov at gmail.com> wrote:
> 11.06.2014 23:00, Lennart Poettering wrote:
>
>> CHANGES WITH 214:
>>
>>          * As an experimental feature, udev now tries to lock the
>>            disk device node (flock(LOCK_SH|LOCK_NB)) while it
>>            executes events for the disk or any of its partitions.
>>            Applications like partitioning programs can lock the
>>            disk device node (flock(LOCK_EX)) and claim temporary
>>            device ownership that way; udev will entirely skip all event
>>            handling for this disk and its partitions. If the disk
>>            was opened for writing, the close will trigger a partition
>>            table rescan in udev's "watch" facility, and if needed
>>            synthesize "change" events for the disk and all its partitions.
>>            This is now unconditionally enabled, if it turns out to
>>            cause major problems, we might turn it on only for specific
>>            devices, or might need to disable it entirely. Device-mapper
>>            devices are excluded from this logic.
>
>
> If we have one exception, I think it is safe to ask another: all block
> devices starting with "zram". The reason is documented at
> http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html :
> it breaks a (mis-?)documented way to integrate zram swap and systemd.

Not so fast, the issue needs to be investigated and explained first.
It is known why device-mapper cannot work with devices which are
open()ed.

By looking at the kernel code, I cannot immediately see why zram's
static devices would have an issue with udev opening the device.

Thanks,
Kay