Hi, On Thu, Jan 14, 2010 at 04:28:11PM -0800, Linus Torvalds wrote: > 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? ] I don't think they read more that they should. Almost all filesystem superblocks are in the first 64kB of the disk, and if you ask for RAIDs probing we also need to seek to the end of the disk ... > 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> Right. The library reads 69kB and uses this buffer for probing rather than call read() for all individual probing functions. I can change the code and call read() on demand for really small sizes. But we still need to check whole 69kB of the disk. [...] > 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? devkit-disks-part-id reads 512 bytes from the device to parse partition table. The libblkid library is trying to detect more that 50 filesystems/RAIDs. > - 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? I had the same question one week ago. This "feature" has pretty bad side effect, see https://bugzilla.redhat.com/show_bug.cgi?id=543749 I hope we will fix this problem. Karel --- Karel Zak <kzak@xxxxxxxxxx> -- 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
