On 06/20/2011 07:16 AM, Karel Zak wrote: > On Sun, Jun 12, 2011 at 03:02:48PM -0400, John Lindgren wrote: >> I noticed blkid causing a noticeable amount of disk hits while >> identifying an NTFS (Win7) partition, and did an strace to find out why >> this was. It seems that the probe_zfs() function does a >> seek-and-read-41-bytes pattern 64 times in the 130 to 520 KB region of >> the partition. > Is it really so big problem on traditional HDDs? Many traditional HD's are rated with a seek time of ~10 ms (though I work with older hardware mostly; newer ones may be better). So by a naive calculation that would make probe_zfs take 0.64 seconds. Now, in the case of probe_zfs, the seeks have good locality, so in practice it will not take that long -- provided blkid is the only program accessing the disk at that time. If the system has some sort of read-ahead process running during boot (as I do), then locality is lost for both blkid and the read-ahead process, and you get thrashing. Also take into consideration that while 64 seeks may not seem excessive in itself, that is for only one filesystem, and blkid checks something on the order of 40 different filesystems. (Fortunately none of the others take anywhere near the number of seeks that zfs_probe does.) Andreas: As far as implementation, I think the ZFS code could be improved by parsing the name-value pair list *before* searching for a valid uberblock, rather than after. I don't have any ZFS filesystems around to test with, or I would try to do this myself. -- John -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
