Inhibiting plug and play

Inhibiting plug and play

[Phillip Susi]

-----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-----

Re: Inhibiting plug and play

[Greg KH]

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

Re: Inhibiting plug and play

[David Zeuthen]

Hi,

On Tue, Jun 18, 2013 at 10:45 AM, Phillip Susi <psusi@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

Re: Inhibiting plug and play

[Phillip Susi]

-----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-----

Re: Inhibiting plug and play

[David Zeuthen]

Hi,

On Tue, Jun 18, 2013 at 11:40 AM, Phillip Susi <psusi@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

Re: [systemd-devel] Inhibiting plug and play

[Lennart Poettering]

On Tue, 18.06.13 13:45, Phillip Susi (psusi@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.

Re: [systemd-devel] Inhibiting plug and play

[Phillip Susi]

-----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-----