[openbeosstorage] Re: Partitioning rethink
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 13 Mar 2003 00:19:19 -0800
On 2003-03-11 at 14:15:27 [-0800], Ingo Weinhold wrote:
> 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.
Okay, as long as we do the right thing where it counts. :-)
> > > 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.
Arg. Makes sense.
> > 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.
Ooops, my bad. I don't actually want to remove full userland
functionality, but I didn't really make that clear. I guess what I was
really getting at was this: what about adding an API to enumerate all
current mountable volumes? That seems like a useful service to provide,
and it has to be implemented for OpenTracker anyway, right? This way it
could be used elsewhere.
> > > > 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.
Well, I did some more reading, and even read through the linux udf
filesystem mailing list archives, and here's what I've come up with:
+ a fileset is a group of files in a directory hierarchy, i.e. the
mountable entity I would otherwise generally refer to as a volume (but
will no longer due to the next point)
+ iso9660 and udf refer to a "volume" as a single side of a disc, be it
CD or DVD.
+ a "volume set" is a set of "volumes", i.e. a multi-DISC set, not a
set of filesets on a single disc sharing data. Hence none of the CDs
we've looked at have had any sort of reasonable volume sequence info,
etc; that's only used for multi-disc sets (I'm trying to get my hands
on my friend's MS VS.NET CDs to see what their volume descriptors look
like).
+ I was thinking udf supported multiple filesets in multiple partitions
per disc, but it's actually the converse(?...I never get those
relations right): it supports single filesets that span multiple
volumes (which actually is kinda-sorta-basically what iso9660 also
supports with volume sets, but udf is more precise about things). udf
also allows the address space of the volume set to be segmented as
necessary (per volume) using partitions that are mapped into a single,
contiguous address space.
+ the inheritable, multi-fileset nature of iso9660 and udf on
multisession media (which DOES appear to supported by udf) appears to
simply be a by-product of the fact that both standards treat the entire
volume on which they reside as legal address space (this point is
partly speculation, based on having seen basically zero references in
the specs to this exact behaviour).
So, since single filesets spanning multiple volumes is part of the
post-R1 plans, I will not plan on supporting that feature in udf until
then (incidentally, I will be starting on a udf filesystem add-on as
soon as justifiably possible :-). This is fine, as we can be standards
compliant and only support single-volume, single-partition udf. This
type of support would also allow us to still support multi-fileset udf
on single multi-session volumes.
I still would prefer we switch to a more generalized partitioning
scheme vs. the current session/partition/filesystem; sorry for pushing
for this so late in the process, but it's taken me this long to figure
out I really don't like the way we're doing things right now.
So, I guess my next task is to try to catch up with the current state
of the whole disk_scanner/DiskDevice API so I can help get things
finished up.
> [...]
> > > 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.
How so (wrt knowing that the thing to be examined is not at the top
level)?
-Tyler
Other related posts:
