All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Hoyer <harald@redhat.com>
To: NeilBrown <neilb@suse.de>
Cc: Jes.Sorensen@redhat.com, linux-raid@vger.kernel.org,
	Kay Sievers <kay@vrfy.org>
Subject: Re: [PATCH 1/1] prevent double open(O_RDWR) on raid creation
Date: Mon, 29 Apr 2013 08:32:31 +0200	[thread overview]
Message-ID: <517E13FF.6050308@redhat.com> (raw)
In-Reply-To: <20130429161124.454e2fc9@notabene.brown>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/29/2013 08:11 AM, NeilBrown wrote:
> On Mon, 29 Apr 2013 07:33:21 +0200 Harald Hoyer <harald@redhat.com> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
>> On 04/29/2013 02:57 AM, NeilBrown wrote:
>>> On Thu, 11 Apr 2013 15:18:33 +0200 Jes.Sorensen@redhat.com wrote:
>>> 
>>>> From: Harald Hoyer <harald@redhat.com>
>>>> 
>>>> This does not trigger the udev inotify twice and saves a lot of blk
>>>> I/O for the raid members.
>>>> 
>>>> Also fixes: https://bugzilla.redhat.com/show_bug.cgi?id=947815
>>>> 
>>>> Signed-off-by: Harald Hoyer <harald@redhat.com> Signed-off-by: Jes 
>>>> Sorensen <Jes.Sorensen@redhat.com>
>>> 
>>> (Sorry for delays.  Thanks for reminders).
>>> 
>>> That patch seems to make sense, but the description above is awfully
>>> thin.
>>> 
>>> Why is double-open a problem exactly?  What does it make udev do?  And
>>> how does that related to ID_FS_TYPE being wrong as mentioned in the
>>> bugzilla entry.
>>> 
>>> NeilBrown
>>> 
> 
>> udevd with watch enabled (inotify on /dev/sd*) gets triggered on close(),
>> when you opened it writeable. So, if you double open() and udev wakes up
>> from the first close(), not all information are written to disk yet, it
>> will not get the ID_FS_TYPE.
> 
>> Seems like the second close() does not trigger an inotify sometimes, so
>> it is missing afterwards all the time.
> 
>> Watch via inotify is just a lazy workaround, so we don't have to modify
>> every tool to emit a "change" uevent, after they changed the disk.
> 
> So udev have a "lazy workaround" so that other programs don't need to
> trigger a change, and as a result, I need to add some special code to
> mdadm. Doesn't seem like I'm getting any advantage out of this laziness.
> 
> How about when udev gets an inotify for a block device, it first checks 
> that it can open it O_EXCL.  If not, it doesn't generate the change event. 
> That seems like the laziest option to me :-)

We cannot open with O_EXCL, because the device can be mounted, and O_EXCL
would fail there.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRfhP+AAoJEANOs3ABTfJwONcP+gOzhDDvWFG0AZdocgttk04o
oV4mr2sde+NtuQMB8ac9v4Y0XP2HnpAYOVAJP7LALpkNHwUYGxtDDbqwWLGQWfPy
xXt6Zq9jE/srwmbBTmCB5sROS5lw6c+M2ft4kza2PDDY+9xyTjxVqVf2tcRGa3Fh
LIFNnKGk58qrgAI/46Muw0rbfMZOpOPuLNrI2aYwl/xmrXmQVXfGLIb+Rms9cdsY
Duk/U05t/DxYupic/fAvkuDmuUzsyBAhpuixL/774m7J3yzf6sNIadtZgy3rMiym
WNz+C8Ltx4d2H1nGmjkw9rKbmnWye15lLfsJGZQxvtt9LkWCPu6L9KbLKQyjjnc9
DBIj/6vID3JhxoLRE7H+zQXk7b9VX6sWAKPo6iFC4LcD8tESs01Jz0bV2kyMcUsZ
1HucYgcd2yzaaMBdEB9LleXd7SCtiBW74qTa/WgFK26notiyIGVWnfBdr9TYi1cB
UJLbsa9XHadq/OW4qVEBWbDbkM6Wpwkc2W7oosh3klauifbn2PXguwp5oeT/CQ1y
HORW36Xt9myAcZWY9iBjFRMwxJNztF89XYWOIzZ5j9fV1wHvCqYqNN+gtyt5vq97
N+Pn4pJ2Nuyygxu++aSv271JBga0YZCIGlIE38J1mJVgZlNAFXIGELs30NhYNhI2
GZ3eOMhawdR9k3NkQbMM
=hDz6
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-04-29  6:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 13:18 [PATCH 0/1] Reduce unnecessary opens of raid members Jes.Sorensen
2013-04-11 13:18 ` [PATCH 1/1] prevent double open(O_RDWR) on raid creation Jes.Sorensen
2013-04-29  0:57   ` NeilBrown
2013-04-29  5:33     ` Harald Hoyer
2013-04-29  6:11       ` NeilBrown
2013-04-29  6:32         ` Harald Hoyer [this message]
2013-04-29  6:53           ` NeilBrown
2013-04-29  8:34             ` Harald Hoyer
2013-04-29  8:40             ` Harald Hoyer
2013-04-29  8:45               ` Harald Hoyer
2013-04-29  8:54                 ` Harald Hoyer

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=517E13FF.6050308@redhat.com \
    --to=harald@redhat.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=kay@vrfy.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.