[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] nested partitions

From: Vladimir 'phcoder' Serbinenko
Subject: Re: [PATCH] nested partitions
Date: Mon, 24 Aug 2009 15:39:47 +0200


On Mon, Aug 24, 2009 at 12:57 AM, Vladimir 'phcoder'
Serbinenko<address@hidden> wrote:
> Rediff
> On Mon, Aug 17, 2009 at 4:34 PM, Vladimir 'phcoder'
> Serbinenko<address@hidden> wrote:
>> On Mon, Aug 17, 2009 at 4:06 PM, Robert Millan<address@hidden> 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
>>> address@hidden
>> --
>> Regards
>> Vladimir 'phcoder' Serbinenko
>> Personal git repository:
> --
> Regards
> Vladimir 'phcoder' Serbinenko
> Personal git repository:

Vladimir 'phcoder' Serbinenko

Personal git repository:

Attachment: nestpart.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]