[ Moving Alan Stern and Greg to the cc, this seems to not be an USB issue as much as a blkid and udev thing. So I added util-linux-ng and Karel and Kay to the recipients list.. 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. Yes. 16 _kB_ per second. Not MB. Which is actually perfectly fine, since the designs you upload to it are generally in the 20kB range. Who cares how fast or slow it is? Except 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? ] On Thu, 14 Jan 2010, Linus Torvalds wrote: > > Right you are. dmesg shows /dev/sdc1, but udev hasn't actually created the > file yet. 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. > I've seen it with two very different computers, so I don't think that's > it. But I did use the same cable etc, so who knows.. Tried a third computer, and different cable. Same deal. Except now your hint made me look at what's going on, and it is indeed all waiting for some ID that will never give any interesting results. On a Fedora-12 machine, it's /sbin/blkid, on an older setup it seems to be /lib/udev/vol_id like Alan said. And it really is the same speed on all computers, so it's simply that the hardware really is that slow. 16kB/s. > > Probably they are caused by udev and hal. Those packages each include > > a program that scans new drives and partitions looking for volume IDs: > > > > /lib/udev/vol_id > > /usr/libexec/hald-probe-{volume or storage, I forget which} > > Will try. Will also double-check with a third computer and a different > cable, just in case. Well, I can make those go away, and then the device shows up largely immediately. However, then I still don't get the automagic mount, so it looks like the fundamental problem is how blkid/vol_id is really slow, and after being really slow it still doesn't actually get any ID. 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 Entering MS-DOS parser (offset=0, size=505856) MSDOS_MAGIC found looking at part 0 (offset 16384, size 505344, type 0x01) new part entry looking at part 1 (offset 0, size 0, type 0x00) new part entry looking at part 2 (offset 0, size 0, type 0x00) new part entry looking at part 3 (offset 0, size 0, type 0x00) new part entry Exiting MS-DOS parser MSDOS partition table detected DKD_PARTITION=1 DKD_PARTITION_SCHEME=mbr DKD_PARTITION_NUMBER=1 DKD_PARTITION_TYPE=0x01 DKD_PARTITION_SIZE=505344 DKD_PARTITION_LABEL= DKD_PARTITION_UUID= DKD_PARTITION_FLAGS=boot 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? - 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. - 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? - What am I supposed to do with a disk that has no UUID? It doesn't get mounted by hald at all. 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) 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. Linus -- 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