From: Loic Dachary <loic@dachary.org>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: puzzling disapearance of /dev/sdc1
Date: Fri, 18 Dec 2015 17:34:38 +0100 [thread overview]
Message-ID: <5674359E.6020006@dachary.org> (raw)
In-Reply-To: <56743502.4010406@dachary.org>
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
Nevermind, got it:
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, and 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.
On 18/12/2015 17:32, Loic Dachary wrote:
>
>>> AFAICT udevd started doing this in v214.
>
> Do you have a specific commit / changelog entry in mind ? I'd like to add it to the commit message fixing the problem reference.
>
> Thanks !
>
>
--
Loïc Dachary, Artisan Logiciel Libre
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2015-12-18 16:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 12:30 puzzling disapearance of /dev/sdc1 Loic Dachary
2015-12-17 13:31 ` Sage Weil
2015-12-17 14:10 ` Loic Dachary
2015-12-17 16:26 ` Ilya Dryomov
2015-12-18 12:38 ` Loic Dachary
2015-12-18 15:31 ` Ilya Dryomov
2015-12-18 16:23 ` Loic Dachary
2015-12-18 16:32 ` Loic Dachary
2015-12-18 16:34 ` Loic Dachary [this message]
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=5674359E.6020006@dachary.org \
--to=loic@dachary.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.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.