[openbeosstorage] Re: Partitioning rethink

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: