[openbeosstorage] Re: Facing the End ;-)

> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > Then the partition module adjusts the partition tables and is 
> > > done.
> > > It would certainly be nice, if the GUI add-on could retrieve more
> > > information about the FSs residing on the partitions of the 
> > > session 
> > > to
> > > be resized, so that it could avoid presenting the user an option 
> > > that
> > > is not feasible. It would probably be sufficient, if a fs=5Finfo 
> > > could 
> > > be
> > > retieved for the FSs.
> > I would *love* to see something like that supported at the OS 
> > level. 
> > Sounds a bit like R2 to me.
> 
> Indeed, we might also (well, *I* want to :-)) introduce a meta 
> partition where OpenBeOS saves the disk state, so that it could 
> support 
> striped disks (RAID) more easily and online partition resizing (i.e. 
> on 
> an active and mounted partition without rebooting), if the file 
> systems 
> allows it.

Wow, resizing while being mounted! Think big, eh? ;-)

> > > requirement for partitioning, it appears to me, that then the GUI 
> > > add-
> > > on can tell, what extactly is supported. 
> > Hmmmm, wouldn't this bind you to using the GUI to perform a 
> > repartition 
> > or resizing=3F Say you have 200 computers, all with identical 
> > partitioning schemes, and you want to resize/repartition them all 
> > to 
> > new sizes, but would rather write a console app to do such a task 
> > than 
> > manually do it via the GUI on each one of them. 
> 
> I am also not sure about the GUI thing here - with OS level support 
> (i.e. those meta partitions) the OS must/should be able to allow 
> reboots (or power offs) while the partition is being resized without 
> losing any data, or halting the boot process.
> (the only difficulty here would be the boot partition - the boot 
> loader 
> might have to support reading the meta data to create the correct 
> partition virtual device).
>
> It would be nice if the GUI app (or any other resizer app) could just 
> continue where it stopped before the crash. Some kind of a journaled 
> partition resizing.

Do I understand you correctly, that you want to be able to resize the 
boot partition while being mounted, abort the process the hard way 
using the power switch and still expect the OS to boot like a charm? 
That's definitely something users of other OSs would be damn impressed 
by. ;-)

> > > * Do I overlook something, or am I right, saying that the 
> > > BBitmaps
> > > (largeIcon, miniIcon) in Device are not needed=3F A GetIcon() in
> > > Partition would make some sense though.
> > Perhaps the same icon is used for all partitions on a given device=
> > 3F 
> > Why 
> > not keep something like Device::GetIcon(), then add a virtual 
> > Partition::GetIcon() that can optionally provide a custom icon=3F
> 
> Yes, might be a good idea. In any way, we could change Tracker as 
> needed to use whatever we want.

I consider that the official green light. ;-)
*evil laughter* ;-))

> > > * Currently I'm not sure how changes of devices are detected. Any 
> > > idea,
> > > how one can find out, whether e.g. the CD has been changed, or 
> > > the
> > > floppy=3F
> > No help here. :-(
> 
> Yes, polling. AFAICT there is no other reliable way. With removable 
> medias, we should check before every write access if it's still that 
> same disk, and if not, unmount and remount it - that requires kernel 
> support for removable media.

What kind of support do you imagine? I thought of a simple notification 
mechanism.

> We should have a unified way to detect disk changes - I think BeOS 
> already has this, but I am too lazy now to look it up.

I just found the B_GET_MEDIA_STATUS ioctl(), if you mean that. It is 
alright for a polling solution for removable media.

> > > * Shall there be a difference between the file=5Fsystem=5Fshort=
> > > 5Fname 
> > > field
> > > in the extended=5Fpartition=5Finfo structure and the fileSystem 
> > > parameter
> > > of the initialize=5Fvolume() (or mount()) function=3F I 
> > > originally 
> > > ...
> > I don't think I see any reason to differentiate between the two. 
> > Particularly if we clearly document the fact that the short name is 
> > used for initialize=5Fvolume() and friends, I don't see why it'd be 
> > a 
> > problem.
> 
> Me too.

OK, I'll adjust the interface.

> > > * I still dislike the partition=5Fcode field in the
> > > extended=5Fpartition=5Finfo structure, since it is partitioning 
> > > system
> > > specific, and therefore IMHO should not be in a generic 
> > > structure. 
> > > The
> > > only reason why it's still there, is that I found it in the
> > > partition=5Fdata structure used for the DriveSetup add-ons. What 
> > > about a
> > > little voting. :-P
> > Tyler: Make it 32-bits and call it a day. :-)
> 
> This partition=5Fcode could only be useful if the fs could determine 
> the 
> partition type. So it could make an additional check:
> if (partition.type =3D=3D B=5FINTEL=5FPARTITION && partition.code =3D
> =3D 0xeb)
>       return validDisk;
> 
> While this could be unconvenient for our users, it would probably 
> increase the compatibility with other operating systems.

That doesn't really convince me, but anyway...

> > > I believe, it is a good idea to break source compatibility, even 
> > > if 
> > > it
> > > is only to replace TypedList by BObjectList and move the classes 
> > > into
> > > an appropriate namespace (BPrivate:: or B* -- I prefer the latter
> > > one)... and maybe rename Device to something less general, e.g. 
> > > BDisk.
> > > But actually I would even change some more things...
> > I say, if we break compatibility, we go all out and fix the static, 
> > messy API as well.
> 
> Right; moving to another namespace would also break binary 
> compatibility, so since we probably know all the victims of this 
> step, 
> I really think we should completely work over the API and make it fit 
> better into the rest of the Be API.

Fine, I will see, if I can prepare a rough draft tomorrow. If then 
still both of you guys are convinced, that the required time will be 
acceptable for R1, then be it so.

> If you do, have also all those future ideas in mind :-)

Argh! ;-)
Seriously, I don't think, striped disk, distributed partitions and meta 
partition stuff should be visible at that level. They look clearly 
kernel-level to me and should be transparent to upper levels. A GUI app 
for specifying the settings for striped disks and for the distributed 
partitions feature respectively, could use a separate interface/
protocol to the kernel. I see no much use for these things in the 
public API.

> > > Anyway, unless there are general objections, e.g. concerning the 
> > > idea
> > > of dropping source compatibility, I will come up with an API 
> > > proposal
> > > (headers and some documentation), that will be relatively close 
> > > to 
> > > the
> > > current one. Don't expect anything before the weekend though. 
> > > Enough
> > > time for bashing. ;-)
> > My only concern is wrt to the OpenTracker changes that would have 
> > to 
> > be 
> > made. And personally, I'm okay with doing the changes; I think it's 
> > worth it just to do the API right the first time. I'm just 
> > wondering 
> > what that OpenTracker guy will have to say to the idea... ;-)
> 
> I guess he would be completely pissed off ;-))
> Seriously, just go ahead and make sure it stays compatible with all 
> current BeOS versions. But be warned it's probably boring work :)

That won't be a problem, I think, but there's still quite some way to 
go, before we reach that point.

CU, Ingo

Other related posts: