[openbeosstorage] Re: Partitioning rethink
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 10 Mar 2003 18:23:18 +0100 (MET)
On Mon, 10 Mar 2003, Tyler Dauwalder wrote:
> I've been reading over the UDF specs the last few days, and having
> done so (along with just working with the disk_scanner stuff so far),
> I'm starting to feel that our borrowed system of
> session/partition/filesystem differentiation is a bit inaccurate and
> limiting. Here are my thoughts:
>
> + There is little, if any, real functional difference between
> sessions and partitions, other than their levels in the partitioning
> tree. Both are a contiguous extent on a device containing some sort
> of useful information; sessions are just currently always at level 0,
> partitions at level 1. If there is no actual "session" or
> "partition", we make up a virtual one to get ourselves up to level 2
> where the filesystems all live.
>
> + Using this system, we're limited to two levels of partitioning. In
> most cases, this is enough. But there are few areas where I'm
> wondering if this will be too limiting:
>
> 1. How are we planning on handling extended partitions in intel
> partition maps? Technically, the partitions inside an extended
> partition should be at level 2, and their filesystems at level 3. And
> one should be able to resize extended partitions using the facilities
> we want to provide. Unless I'm missing something, there's no good way
> to accurately express the relationship of extended partitions to
> their child partitions using our current scheme.
Actually the example is not very apposite, since the (non-)standard for
the intel partition maps doesn't define that the extended partition must
space-wise comprise its logical partitions. Some operating systems and
tools require that, but others don't (e.g. the module I wrote ;-).
However, you're right, other partitioning systems (Apple?) may allow for
nested partitions; maybe even arbitrarily deep. With our current scheme
the responsible partition module would need to flatten that structure.
One might argue, that this is natural, since in general the user apps
would not need to be bothered with the administrative structure of the
partitions.
Note, that I'm talking about the API here. For resizing the partition GUI
add-on would get all necessary information (i.e. also the structural
ones) via the parameters from the kernel module.
> 2. UDF supports the concept of multiple volumes *and* (I believe; I'm
> still slightly sketchy on this...) multiple partitions in each volume
> at the filesystem level. Now, we don't technically *have* to support
> those features (there are 3 levels of interchange, and only one must
> be supported to be compliant; the lowest level just supports a single
> "partition" in a single "volume"), but I don't really see any great
> reason not too (particularly since most DVD media does not support
> more than a single session with a single track, meaning UDF
> partitions are the only way to support multiple volumes on a single
> DVD). And if we do, say someone puts a UDF volume with multiple
> partitions on a hard disk, inside an intel partition that's inside an
> extended partition (not likely, but plausible)? Our current
> session/partition/filesystem partitioning scheme will fall short of
> describing what's actually going on.
I see. As it appears to me, that things are a bit more difficult anyway,
since the partitioning is at FS level.
> Therefore, it seems reasonable to me to consider switching to a more
> general partitioning scheme that allows for an arbitrary level of
> nested partitions. CD/DVD sessions would be treated as one type of
> partition, as would intel partitions, UDF volumes and partitions,
> etc. Instead of having session/partition/filesystem modules, we'd
> either have just one type of recognizer, or possibly device property
> based recognizers used only at level 0 (a la CD/DVD sessions, where
> the partition data isn't part of the data stream) and data stream
> based recognizers used everywhere else (a la intel partitions,
> iso9660, etc.). Thoughts?
I like the idea of supporting nested partitions and in principle I don't
see a problem with dropping the different treatment of sessions and
partitions -- the only additional information a session structure/object
currently provides, is whether it is a data or an audio session, but that
can be incorporated easily.
Regarding the recognizers: Does it make a difference whether there are one
or two types? Well, one could skip the non-data-stream-based ones when
examining an inner partition, but that doesn't really matter, does it?
> On a side note, I'm now really excited about supporting UDF in BeOS;
> the format is designed such that we'll be able to burn file
> attributes along with regular file data and still have the files
> accessible from other OSes. And I believe relevant indices could also
> be burned as well. :-)
Cool! :-)
> p.s. In case you're curious, I've emailed you both the ecma standard
> that UDF is a specialization of (incidentally Axel, it turns out that
> this is that "other" standard I was looking at a few meetings ago
> while trying to figure out iso9660 volume set stuff... I had no idea
> at the time it was used by UDF :-). The UDF standard itself is at
> http://www.osta.org
Thanks. I will be reading it when I find some time. Though time is
currently a rare resource for me. Should be better in a couple of days, I
hope. BTW, I'm not sure that I can make it to the admin meeting tonight.
As a brief update of my laptop status: Unfortunately the stores I visited
were less cooperative than expected, when I came for trying my BeOS CD.
So I bought a machine blindly in a shop with the right for return in the
first two weeks. An Acer TravelMate 426, with almost all components one
could wish being supported under BeOS (Radeon, AC'97 sound, built-in
network, USB,...). Nevertheless I will return it in a few days, since I
will try a Vobis laptop (ordered via internet) which has better components
for the same price -- in particular a 1400x1050 display.
In case I'm not happy with that one, I will return it (,wait until I get
my money back) and buy the Acer one again. So, I hope this chapter will be
over quite soon.
CU, Ingo
Other related posts:
