[openbeosstorage] Re: Partitioning rethink
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 13 Mar 2003 17:07:14 +0100 CET
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> 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=3F That seems like a useful service to
> provide,
> and it has to be implemented for OpenTracker anyway, right=3F This way
> it
> could be used elsewhere.
OpenTracker also displays volumes that aren't mountable. Perhaps we
should just have a "mountable" flag=3F In any way, if there is no file
system for this partition, it just can't be mountable :))
> 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:
> ...
Thanks for digging so deep into this stuff :-)
> 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.
Very nice! If you need any help with that (moral support and so on ;-))
I'll be glad to help out. Having UDF support would be really great
(even for R1) - do you plan on doing write support as well=3F
> 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=5Fscanner/DiskDevice API so I can help get things
> finished up.
That would be nice. I don't think that this would be a big change, as
Ingo already said (and that's mostly why I think that :)) - switching
to a naming scheme that implies more info about the on-disk layout
should be "almost trivial" :)
Adios...
Axel.
Other related posts:
