On Mon, Aug 17, 2009 at 4:06 PM, Robert Millan<r...@aybabtu.com> wrote: > On Mon, Aug 17, 2009 at 03:00:52PM +0200, Vladimir 'phcoder' Serbinenko wrote: >> Rediff and few fixes > > Please note that after what we discussed on IRC, we need to find a solution > that wouldn't make boot time increase linearly with the number of filesystems > or partmaps GRUB supports. > It probe time scales linearly no matter what we do. Fortunately with disk cache few first sectors are read and checked for different signatures which is fast. As for module autoload with search patch it doesn't happen except in the failure to access requested device. > I really think supporting every sort of combination is too extreme. For > example who would want an msdos/msdos chain? OpenSolaris creates one, but > it's a false positive. > minix does it and it's not a false positive. > The overall idea *is* nice. Some combinations (e.g. msdos/bsd) are cleaner > this way, but supporting everything doesn't scale well. AFAIK no partmap goes beyond first 16K for signature checking. Time for signature checking can be neglected and 16K would be read for filesystem probe too. Additionally e.g. (hd0,1) is probed for subpartitions only if (hd0,1,X) is requested or we're scanning through partitions. In last case we're likely to fsprobe partition anyway so it doesn't create any overhead > > Perhaps we can explicitly list which combinations make sense? So when an > msdos label is found, its partitions are probed for bsd labels too, but not > for msdos labels again, etc. > > -- > Robert Millan > > The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and > how) you may access your data; but nobody's threatening your freedom: we > still allow you to remove your data and not access it at all." > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel >
-- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
