FreeLists / openbeosstorage / [openbeosstorage] Re: Partitioning rethink

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Thu, 13 Mar 2003, Tyler Dauwalder wrote:

> On 2003-03-11 at 14:15:27 [-0800], Ingo Weinhold wrote:
[...]
> > > 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.

Actually the DiskDevice API provides a means to enumerate all mountable
partitions: BDiskDeviceRoster::VisitEachMountablePartition(). Or is there
something you don't like this method for?

[...]
> 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:
[...]

Sorry, I haven't yet found the time to read through the specs you send us.
:-(
When I will have done it, I'll re-read the mail and complain noisily, if
there is something I disagree on -- not that I'm expecting that. ;-)

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

Cool! I can tell you, writing FSs is fun. And have Axel send you his
improved FS shell, in case he doesn't manage to check it in before. :-P

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

Good deal.

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

No worries, I always suspected something evil to happen, since everything
worked out just too well. ;-)

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

As far as I remember, there's not too much left to be done in the API
implementation. Basically the support for partitioning and FS
initialization. With the former one I've already started, and it shouldn't
take me that long to finish it, once my laptop problem is solved.

It would be great, if you could work on ideas, how the DiskDevice API
should be changed (or rewritten) to reflect a generalized partitioning
scheme. You know, like proposing new headers and such.

If that is done, we can think about how to move the DiskDevice API related
functionality from the registrar into the kernel and how we want to adjust
the disk_scanner API and the interface for the modules. That would be my
vision for the further proceeding. Does that sound reasonable?

> > [...]
> > > > 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)?

Er, well, that has to do with my idea to change the disk_scanner module
interface I have not yet made publicly known. ;-) In fact it's merely the
skeleton of an idea, and that's why I haven't mentioned it yet.

When we were discussing the ISO9660 volume groups it occured to me,
that the modules simply get too few information. In that particular case
the iso9960 FS module -- it had to know former sessions/volumes, but would
not, unless rescanning the whole disk again.

And since the thought to move the registrar functionality into the kernel
came up, it seemed like a clever solution to supply the module with a
RPartition (the registrar equivalent of a BPartition) object. It could
simply get the parent objects (RSession, RDiskDevice) and traverse the
tree in its current state at will, inspecting former
RSessions/RPartitions of interest.

Similarly the other modules would get respective objects. With the
suggestion to unify the notions of sessions and partitions, still the
parent object could be supplied, which would be either a RDiskDevice or a
RPartition (i.e. two hook functions), or a common base class of which one
could get the type info, if needed.

As said before, this is just a rough idea, not worked out in detail. Axel
may for instance object, that C++ in the module interface is not exactly
something he likes -- which could be worked around by using ugly ;-) C
structures instead -- or something else I don't think of, and perhaps
wouldn't have an answer to...

CU, Ingo