Date: Wed, 24 Dec 2008 08:55:59 +0200 From: gelraen <gelraen.ua@gmail.com> To: "Marcel Moolenaar" <xcllnt@mac.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Andrew Thompson <thompsa@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now Message-ID: <ac42db050812232255p69cbb095h2d660d4d9b4d0b6f@mail.gmail.com> In-Reply-To: <A3628E7B-4D26-4A1E-A537-610E59CE47BD@mac.com> References: <ac42db050812201132s7c2ca7bekc9c0e60a728314ce@mail.gmail.com> <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <ac42db050812231103j54087613gffad2827eba14a03@mail.gmail.com> <A3628E7B-4D26-4A1E-A537-610E59CE47BD@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/12/23 Marcel Moolenaar <xcllnt@mac.com>:
>
> On Dec 23, 2008, at 11:03 AM, gelraen wrote:
>
>> I spent some time in thinking about the best way to implement naming
>> of extended partition.
>> IMO, the only reasonable way is to sequentially numerate slices. So
>> the result may look like this:
>> ad0s3s1 ad0s3s2 ad0s3s3 ad0s3s4 ad0s3s5 ....
>
> Well, the question is whether to expose the nesting
> in the naming or use a flattened partition naming
> scheme. Secondly, how generic do you want to make the
> flattening.
>
> With flattening, you have ad0sX, with X from 1 to many.
> Without flattening you get ad0sX[sY...], with X and Y
> from 1 to 4.
>
> What you suggest is a partial flattening: adsXsY, with
> X from 1 to 4 and Y from 1 to many.
>
> The question of how generic you want to make it, relates
> to having a BSD label under a MBR or a MBR under a GPT
> and whether to flatten the namespace. As an example, you
> can limit flattening for nested partitions of the same
> type (i.e. same-scheme nesting).
>
>> Main problem here is detecting which type of naming to use in particilar
>> case.
>
> Exactly. This requires information exchange between level
> X-1 to level X of the nesting. Such an exchange already
> exists for example: the absolute sector offset of the
> partition is passed from level X-1 to level X. So, it's
> definitely doable.
>
> In short: we just need to nail down what we're going to
> fix, if we're going to fix anything, and understand the
> consequences of our choice so that we can document it
> or beter, avoid introducing new bugs in the process..
>
> --
> Marcel Moolenaar
> xcllnt@mac.com
>
Let's see what we have:
Slices on extended partition is *not* actually nested, they form a
some sort of chain.
Single entry in parent (level 1) PT is sized to whole extended
partition. Nothing unusual.
Next, 1st PT of extended partition contain two entries:
1st entry) normal slice (level 2), which can contain some FS or be
a target for partitioning
2nd entry) pointer to next slice in next format:
- type field set to 0x05 (Extended DOS)
- start sector points to next PT
- size is equal to size of next normal slice plus skipped
sectors (63 in my case)
"Anomalies" starts from 2nd PT:
1st entry) normal slice (level 2). Start sector specified
relatively to position of current PT and (which is equal) to start
sector value in previous PT
2nd entry) again, pointer to next PT. Most important here, that
start sector calculated relatively to whole extended partition, not
current PT, and points to somewhere outside of area specified by 1st
entry and corresponding entry in previous PT.
>From my point of view, it is some strange and confusing design, but it
allows creating of potentially unlimited number of slices in not very
complicated way.
Description of PTs in extended partition can be generalized for using
the same code for all PTs and extending possibilities:
1) start sectors for all, entries except marked as Extended DOS,
used relatively to current PT.
2) for entries marked as Extended DOS we count start sector
relatively to whole extended partition and there are three cases:
2.1) pointed PT contains extended entry which safely can be
nested (all offsets and sizes specified correctly, no overlappings and
running out of bounds)
2.2) pointed PT contains extended entry which runs out of
bounds, but can be correctly processed as a part of chain
2.3) pointed PT does not contain extended entry
In case 2.1 we increase nesting level. For 2.2 and 2.3 slices are part
of chain and should be flattened. All other cases considered as
invalid.
Little comment for case 2.3: it also could be nested, but to avoid
renaming after adding "chain"-style partition in it's PT better to use
it as a part of chain.
With such design it would be possible to combine chains of partitions
and really nested partitions.
Even more, it would be possible to form "branchy" chain (i.e. one of
PTs contains 2 entries which couldn't be nested)
Correct me, pls, if I miss something.
P.S.: As I think, proposition written above, describes more powerful
implementation that could be needed in real life. Extended partitions
takes it's history from dark DOS times and AFAIK there are no
implementations with real nesting, not just chaining, so it would be
fully enough to implement only proper processing of chains.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac42db050812232255p69cbb095h2d660d4d9b4d0b6f>