[openbeosstorage] Re: Partitioning rethink
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 11 Mar 2003 23:15:27 +0100 (MET)
On Mon, 10 Mar 2003, Tyler Dauwalder 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. :-)
I think, sane implementations do so, but, as I said, not all require it.
Our GUI add-on would, of course, do The Right Thing (tm) and allow only
creation of logical partitions inside an extended partition, but would
nevertheless deal gracefully with drives partitioned differently.
> > 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.
According to the DriveSetup add-on it doesn't. But that doesn't mean
anything.
> I'm sure somebody somewhere does though. :-)
That's for sure. :-)
> > 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?
No, both would use the C++ API, which in turn uses the disk_scanner API.
> 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)?
For the kernel part I agree. It should have all information. But
nevertheless I would provide the full functionality in userland, too, via
the C++ API. Pretty much as done now.
> > > 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.
OK, I see.
[...]
> > 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).
Yes, a flag would do. Though in case of a CD, that wouldn't be necessary,
since the module would know itself, that the thing to be examined is not
at top level, and thus could just reject it without doing anything at all.
[laptop hunt]
> I'm exhausted just reading about it. Ech. Good luck. :-)
Thanks. :-)
CU, Ingo
Other related posts:
