Hi,
On Tue, Jun 18, 2013 at 11:40 AM, Phillip Susi <psusi@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
