On Wed, Jun 11, 2014 at 8:49 PM, Alexander E. Patrakov <patra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel