-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2013 08:53 AM, NeilBrown wrote: > On Mon, 29 Apr 2013 08:32:31 +0200 Harald Hoyer <harald@xxxxxxxxxx> wrote: > >> -----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@xxxxxxxxxx> >>> 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@xxxxxxxxxx wrote: >>>>> >>>>>> From: Harald Hoyer <harald@xxxxxxxxxx> >>>>>> >>>>>> 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@xxxxxxxxxx> Signed-off-by: >>>>>> Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> >>>>> >>>>> (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. > > > If the device is mounted, why would you want udev to be doing anything to > it? > > I assumed this was for things like "mkfs" so that as soon as you mkfs a > filesystem udev could tell udisks to immediately mount it... though I'm > not sure this is a good idea. > > I'm probably missing something important: what is the particular use case > for udev mapping a close-after-write to a change event? > > Thanks, NeilBrown Well, you would not recognize LABEL or UUID or MD UUID changes, if you don't call blkid after a mkfs or mdadm or lvm action. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRfjCeAAoJEANOs3ABTfJwLQIP/iaKQFUYyE5tsw8zVVxw+ag6 QPhs08y8JM1nPNyC4hd2BKLwx687eXVIR7Kyfx8i9L2dEHLn2ry+ROTAbfn1UEr2 GjpD48wuNiohJKUZ5l8Wn3q8slboUImgHUkiZgtWII0pCk3vGo+/01WIWzSzDRlN PsI8TS4+wBIdZhfWMtzU65uXiZYoGpaURqIv+7xIgEN90mM45kE1FA/HJF8YZOBz H8CMI2pr+GUI/XCUjUYJK5m3y1sJCm5US5IsR4AqpQGlkU2G9pFQYRWFS4uYKOsF tjk7Fj8wFw51gz/dWGlKM9uK+iAFHVVorjFPdDJilSdswWP88JMrwlfAkivxbKSA 6JsKEOSLlkuW5gNRl6Flg2/hLBmlJYUx3nXzT4WZWgibD4mkKAmY1uB0gnzE2/lm YP7dEs5WVo5Rl3lM+Mv6vqDl6dJCvg60AU3u5srWwfqUau81p5rYIuqXJ5Da4GcU njz6NUwzMm2FI91INDDi/GJzwi1bVV6CeTNiz3LNjd2+yr2dt0AFBZWQ3k1c+/rO WJ8NhN6dW8JZEL4VN5yfEht4x+kVnxqdTedAm5NtPooSD3we2w/e5u5im3FfUkJN GX4+Et2sE5gk70Es/u2Ws1tLOdpxZsUiU/HBgS51+8KBIumj+Me3BLZpGkvqwNm/ vV2Fov6yJhM5E0/lYAhn =xI4C -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
