On Fri, Jan 15, 2010 at 01:28, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > Background: I have a _really_ slow USB disk-like device. Or more > properly, my wife does - it's an embroidery machine that has a USB > storage interface. And the thing gets about 16kB/s. > it takes about half a minute to show up as a disk, because udev > and blkid take _forever_, and try to read a hell of a lot more than > they should. Can somebody please fix this? > Yeah, and it is indeed waiting for blkid (and then later apparently > hald-probe-volume). I had stupidly thought that udev would create the > trivial device names that don't need any translation immediately. Not so. > On that machine, with the embroidery machine plugged in: > > [root@EeePC torvalds]# time blkid -o udev -p /dev/sdc > > real 0m13.736s > user 0m0.002s > sys 0m0.007s > > and: > > [root@EeePC torvalds]# time blkid -o udev -p /dev/sdc1 > ID_FS_SEC_TYPE=msdos > ID_FS_VERSION=FAT12 > ID_FS_TYPE=vfat > ID_FS_USAGE=filesystem > > real 0m13.491s > user 0m0.003s > sys 0m0.005s > > ie it took a total of 27s+ to just do blkid on first the whole disk (which > had nothing on it, of course), and then the first partition (which just > has an empty FAT filesystem on it). > > Half a minute to figure out something like that, and then it doesn't even > mount anything, apparently because it has no UUID! > > The reason is almost purely that it does this: > > 15:51:05.466494 _llseek(3, 0, [0], SEEK_SET) = 0 <0.000107> > 15:51:05.466930 read(3, ""..., 69632) = 69632 <8.186289> > > ie it does that one large read (which is indeed big enough that the kernel > will start read-ahead, so the 68kB read turns into a 120kB one) > > There's a few other ones that are in the "just under a second" range > because this thing is a really slow disk, but that one read obviously > accounts for 60% of it all. > > After it has done the blkid on both devices, it then also does > > /lib/udev/devkit-disks-part-id /dev/.tmp-block-8:33 > > which takes an additional second, and results in > so that udev tool gets all the same information, and does it _much_ > faster. > > So a few questions: > > - can we please not use 'blkid' at all in udev? It looks like the udev > native 'devkit-disks-part-id' is much better at this, and since udev > does it _anyway_ afterwards, how about doing it up-front instead? blkid is udev's native tool, and we need to use it. But we need to optimize its use with devices like this, I guess. It's similar to plain old floppy drives which do not behave well when tried to read all sort of signatures at random places. :) The devkit-disks-part-id thing is part of DeviceKit-disks, the HAL successor, and does only parse the partiton table in the first blocks of the volume, and nothing else. This tool will entirely go away and be replaced by the (now existing) partition table parsing code in blkid. > - maybe blkid could be improved to not be such a pig. Even if you don't > have a really slow device like mine, I bet people could see some of the > same issues with a USB floppy drive. I've never seen so far issues like this. and yes, the blkid use needs to get smarter in this case. > - Why do we try to even identify /dev/sdc, when the kernel has already > partitioned it and we'd be much better identifying just the partition? It's the too-dumb in-kernel partition parsing. For some devices the kernel creates partitions because it is too dumb to find out, that the device contains a RAID signature or other metadata that signifies, that this device should not be handled. Many RAID signatures are at the end of the device, or at least still allow that the volume contains a partition table at the beginning of the device, which the kernel will find. Udev needs to look at the disk, if there are such RAID signatures, and then it needs to handle it, and in many cases just kill all the wrongly kernel-created partitions. The thing is that if the kernel is in the business of creating partitions for anything but the boot device, it should better know all metadata of possible RAID volumes, especially all of them that invalidate any partition table setup -- but that's not the case so far. Userspace needs to fixup what the kernel has wrongly created in quite a few cases, that's why the disk is searched for known signatures, even when there are partitions already. In your specific case, there is not much point in doing all that, very true. Seems blkid is not optimized for such slow devices so far, which we should try to do now. > - What am I supposed to do with a disk that has no UUID? It doesn't get > mounted by hald at all. On GNOME, it should be Nautilus which requests the mount from the DeviceKit-disks service. HAL is not used anymore, and is expected not to be needed in future distro releases like Fedora 13. > That kind of sucks. I'd like to see the > filesystem, despite it not having an ID. Or maybe it doesn't get > mounted for some other reason (I thought it was just because everything > was so slow and the disk read failed when it tried to mount things, but > since this is all driven by udev anyway, I'm now assuming that that > wasn't the case, and it's the missing uuid) Nothing should depend on a UUID found on the volume to trigger automounting. The stuff you've shown earlier: $ blkid -o udev -p /dev/sdc1 ID_FS_TYPE=vfat ID_FS_USAGE=filesystem should be enough to make automounting work. > And no, I can't just add a UUID to the thing. It's a piece of external > hardware with odd firmware that I don't control. Yeah, seems odd, that this does not work, event when it would take a minute. Does it show up in Nautilus, so that you can click on an icon to mount it, or does it not show up at all? After all has settled, does: devkit-disks --dump print anything useful about this device? Let's find some possible way to optimize this behavior. It seems all comes down to optimize the blkid usage, as HAL should go away (or at least get crippled not to matter anymore) before the next release anyway. How large is the volume? If it's very small, maybe we could add logic to skip the probing for any RAID stuff, which can not really exist on such small volumes. Should we disable or limit the read-ahead logic with BLKRASET? That might possibly cut the time down to the half, right? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
