Re: [systemd-devel] Inhibiting plug and play
On Tue, 18.06.13 13:45, Phillip Susi (ps...@ubuntu.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Various tools, but most notably partitioners, manipulate disks in such a way that they need to prevent the rest of the system from racing with them while they are in the middle of manipulating the disk. Presently this is done with a hodge podge of hacks that involve running some script or executable to temporarily hold off on some aspects ( typically only auto mounting ) of plug and play processing. Which one depends on whether you are running hal, udisks, udisks2, or systemd. There really needs to be a proper way at a lower level, either udev, or maybe in the kernel, to inhibit processing events until the tool changing the device has finished completely. The question is, should this be in the kernel, or in udev, and what should the interface be? So, Kay suggested we should use BSD file locks for this. i.e. all tools which want to turn off events for a device would take one on that specific device fd. As long as it is taken udev would not generate events. As soon as the BSD lock is released again it would recheck the device. To me this sounds like a pretty clean thing to do. Locks usually suck, but for this purpose they appear to do exactly what they should, and most of the problematic things with them don't apply in this specific case. Doing things way would be quite robust, as we have clean synchronization and the kernel will release the locks automatically when the owner dies. Opinions? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/16/2013 1:23 PM, Lennart Poettering wrote: So, Kay suggested we should use BSD file locks for this. i.e. all tools which want to turn off events for a device would take one on that specific device fd. As long as it is taken udev would not generate events. As soon as the BSD lock is released again it would recheck the device. To me this sounds like a pretty clean thing to do. Locks usually suck, but for this purpose they appear to do exactly what they should, and most of the problematic things with them don't apply in this specific case. Doing things way would be quite robust, as we have clean synchronization and the kernel will release the locks automatically when the owner dies. Opinions? Sounds like it might work. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR5YRIAAoJEJrBOlT6nu75VLUH/3X7fHhppdUCw5WFt1PpitKK O9tuPcs9RZBWhaQ+Ol9Sp82qnEG+mqmmCLAc3z35Zj1PpNRKTLYrGWbmqlbkPsks ZU4UZTnr9i03uDRuQfSMtUsTpnriBILT8tfyPkH7XYulGBligI3D3Sdk6LWD6Y6J tm0SnVlOk/tm4FasWFT4KlFp/obRuL8yUBnZvgYqyTblCeVTX2013xEtXN/TG9pH 4iNSgRTQ98K/EdZQP1yz2j/LSLn0MFQTCPU4YuDVmds9nU2iZAllaY+sSMQCSkm6 Ks4giagyhKsBw8oy3AAN5f/VEvpriuAAVrLxNNaTzTAfR//J7gHwzB40ploB3oo= =+o3u -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
On Tue, Jun 18, 2013 at 01:45:09PM -0400, Phillip Susi wrote: Various tools, but most notably partitioners, manipulate disks in such a way that they need to prevent the rest of the system from racing with them while they are in the middle of manipulating the disk. Presently this is done with a hodge podge of hacks that involve running some script or executable to temporarily hold off on some aspects ( typically only auto mounting ) of plug and play processing. Which one depends on whether you are running hal, udisks, udisks2, or systemd. There really needs to be a proper way at a lower level, either udev, or maybe in the kernel, to inhibit processing events until the tool changing the device has finished completely. The question is, should this be in the kernel, or in udev, and what should the interface be? What events are you wishing to inhibit? And who is in control of them? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
Hi, On Tue, Jun 18, 2013 at 10:45 AM, Phillip Susi ps...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Various tools, but most notably partitioners, manipulate disks in such a way that they need to prevent the rest of the system from racing with them while they are in the middle of manipulating the disk. Presently this is done with a hodge podge of hacks that involve running some script or executable to temporarily hold off on some aspects ( typically only auto mounting ) of plug and play processing. Which one depends on whether you are running hal, udisks, udisks2, or systemd. There really needs to be a proper way at a lower level, either udev, or maybe in the kernel, to inhibit processing events until the tool changing the device has finished completely. The question is, should this be in the kernel, or in udev, and what should the interface be? When I was younger I used to think things like this was a good idea and, in fact, did a lot of work to add complex interfaces for this in the various components you mention. These interfaces didn't really work well, someone would always complain that this or that edge-case didn't work. Or some other desktop environment ended up not using the interfaces. Or some kernel hacker running twm (with carefully selected bits of GNOME or KDE to get automounting) ran into problems. It was awful. Just awful. What _did_ turn out to work really well - and what GNOME is using today and have been for the last couple of years - is that the should_automount flag [1] is set only if, and only if, the device the volume is on, has been added within the last five seconds [2]. It's incredibly simple (and low-tech). And judging from bug reports, it works really well. So please don't add complicated inhibit interfaces. They're probably not going to work and probably not everybody is going to use them. Thanks, David [1] : as used in GNOME and probably things like Ubuntu Unity and XFCE as well, see https://developer.gnome.org/gio/2.35/GVolume.html#g-volume-should-automount [2] : this is where should_automount is being set https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2volume.c?id=1.17.2#n377 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
Hi, On Tue, Jun 18, 2013 at 11:40 AM, Phillip Susi ps...@ubuntu.com wrote: I don't follow. You mean udisks delays auto mounting by 5 seconds? No, it works like this: if you plug in the device, then - for example - /dev/sdb is added and then /dev/sdb1 is added and /dev/sdb1 is deemed to contain a FAT filesystem that could be mounted. The trick is to only decide to automount /dev/sdb1 if /dev/sdb appeared recently - e.g. within the last five seconds. The problem also goes beyond udisks and auto mounting, which is why I say it really needs done either at the udev or kernel level. Disagree. We don't want this level of complexity in either the kernel or udev. Why? Because it can be solved by the policy manager (such as the GNOME auto-mounter described above or the RAID auto-assembly machinery described below) do the right thing - e.g. be extremely careful before it's doing something (such as mounting it or assembling several of them to a RAID or VG) to a device. For instance, a udev script may identify the new volume as part of a raid ( leftover metadata ) and try to attach mdadm to it, at the same time you're running mkfs. I'm also pretty sure that I have seen the mdadm udev script race with mdadm itself while you are trying to create a new raid volume. This is indeed a problem with the RAID auto-assembler being overeager and not careful enough. In fact, I routinely just delete udev rules for RAID and LVM assembly because they keep doing the wrong thing. The solution here is not to add complex machinery and frameworks and abstractions. The solution is simply to fix the underlying problems, not paper over them. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Inhibiting plug and play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Various tools, but most notably partitioners, manipulate disks in such a way that they need to prevent the rest of the system from racing with them while they are in the middle of manipulating the disk. Presently this is done with a hodge podge of hacks that involve running some script or executable to temporarily hold off on some aspects ( typically only auto mounting ) of plug and play processing. Which one depends on whether you are running hal, udisks, udisks2, or systemd. There really needs to be a proper way at a lower level, either udev, or maybe in the kernel, to inhibit processing events until the tool changing the device has finished completely. The question is, should this be in the kernel, or in udev, and what should the interface be? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwJylAAoJEJrBOlT6nu75TlAH/1Eso89Jta4AFn/ynYZUWwVD xS1Nm8ZbRHQizBFmv5rq5Yunr6XUcUQlux9EeG81QwgJ2mgOAk3XE2ldzOp0lUei cqQYsrdWKHXz8ZXpNG1Jsgw77EUyrs39Z6NmNC+X1AcFbzxRXplGMTJfRSWtW3bw Ngi8MCjKZOx/qNzUcyZnR3tdAF0veLHWtr7j5XvgO+/iomnAxIOcYiSCv1OeDMdX SCx8bULT4/LaRWzbcmpzmh1irMsXavrOwuPzIGBTdMKhByyxnwxiOdIyhOs1OJda 059zK7CxMNidD37ON9hMyMtYz5BeCzZmPJdJ6Ef4G7ZrH++xiI4cGvgVOClP6vI= =Ym1b -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/18/2013 2:03 PM, David Zeuthen wrote: When I was younger I used to think things like this was a good idea and, in fact, did a lot of work to add complex interfaces for this in the various components you mention. These interfaces didn't really work well, someone would always complain that this or that edge-case didn't work. Or some other desktop environment ended up not using the interfaces. Or some kernel hacker running twm (with carefully selected bits of GNOME or KDE to get automounting) ran into problems. It was awful. Just awful. I can't really extract any meaning from this without knowledge of what was tried and what problems it caused. I also don't see why it can't be something as simple as opening the device with O_EXCL. What _did_ turn out to work really well - and what GNOME is using today and have been for the last couple of years - is that the should_automount flag [1] is set only if, and only if, the device the volume is on, has been added within the last five seconds [2]. It's incredibly simple (and low-tech). And judging from bug reports, it works really well. I don't follow. You mean udisks delays auto mounting by 5 seconds? That's not going to help if, for instance, you use gparted to move a partition to the right. It first enlarges the partition, which generates a remove/add event, then starts moving data. 5 seconds later udisks tries to mount the partition, which very well may succeed with horrible consequences. The problem also goes beyond udisks and auto mounting, which is why I say it really needs done either at the udev or kernel level. For instance, a udev script may identify the new volume as part of a raid ( leftover metadata ) and try to attach mdadm to it, at the same time you're running mkfs. I'm also pretty sure that I have seen the mdadm udev script race with mdadm itself while you are trying to create a new raid volume. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwKm1AAoJEJrBOlT6nu75ZqMIAM/EUrDIQQn6O5dlCMAOwGSm h/D5Pbb6amPmDiFELooQgb+BMuUw9bAYwdcukMWZB1MqBTMBOtwLGTeI9TEeWH4y y2c753e2JBgkPnzY6iFkfPXDvsTEIZSHsx00YLZt06aDL5k/Fmt5eN+mD5pSiC2T l1qSdhtEw2IseWVuXOjwjy5K00vIDDAaLG1o2Ff135gNx/wUaOK8nL0vSUZhDK96 V3WS4LGKJDlrGESeAyDELfuExrvtmASgohlpUEy2IK9R9lpNicudStPDZFp+dzCA wv/D1HXkZiIRS74u6Nl3BLtWWd9rPF0ub2OXKCwURYXl2ULE7bPwaiJIdtYp/zo= =BWbx -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
