[openbeosstorage] Re: Partitioning rethink

> > 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 ;-).

Hmmmm... What's the reasoning there? It just doesn't feel right to me 
not having the extended partition actually contain the logical 
partitions... I guess I've used Partition Magic too much. :-)

> However, you're right, other partitioning systems (Apple?) 

I'm not sure by any means, but from the little exposure I've had with 
my iMac, it doesn't look like Apple's partitioning system supports 
nesting. I'm sure somebody somewhere does though. :-)

> 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.

Darn, I knew I forgot something.

The current plan has been to use the DiskScanner C++ API for 
OpenTracker, and the partitioning parameters API for DriveSetup type 
stuff, correct? The thing is, OpenTracker is really only concerned with 
mountable volumes, correct? So why not make the disk_scanner stuff an 
accurate representation of reality, thus allowing it to be used for 
partitioning, etc., and then provide an API in the kernel on top of the 
disk_scanner (which will have an up to date image of the current state 
of all the devices at any given time) that enumerates all the mountable 
volumes in the system (and which will also contain the volume set 
grouping info)? 

> > 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.

Well, the two are reasonably separate: there's a volume recognition 
sequence that enumerates volumes and partitions, and then each 
partition has its own "filesystem" inside it. 

> > 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.

Yes, I was just thinking each partition should have a type identifier 
associated with it.

> 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?

I guess it won't matter as long as we flag the device-level partitions 
so the session module (which will need a higher priority than any data 
stream based modules) doesn't needlessly read the table of contents 
when stepping through a CD (especially if it had a complex UDF image on 
it).

> > 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. 

Well, I'm starting to do better myself, but I'm still having a hard 
time getting stuff done these days. IOW, don't worry, there's no hurry 
:-).

> BTW, I'm not sure that I can make it to the admin meeting 
> tonight.

I'd have a hard time too if it started at midnight for me. :-)

> 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.

That was my experience as well... We really need a version that can 
boot and run all off of a 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,...). 

Wow, I'm impressed. :-)

> 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.

1024x768 isn't as bad as I'd thought it'd be... :-) I still wouldn't 
mind a 1400x1050 though.

> 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.

I'm exhausted just reading about it. Ech. Good luck. :-)

-Tyler

Other related posts: