[openbeosstorage] Re: Facing the End ;-)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 23 Jan 2003 16:27:29 +0100 CET
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.
> > 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 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.
> > * 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.
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.
> > * 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.
> > * 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.
> > 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.
If you do, have also all those future ideas in mind :-)
> > E.g. remove a couple of public setter methods or make them private.
> > Partition has bunch of them, but I actually don't see why. The
> > Tracker
> > uses three (SetMountState(), SetMountedAt() and SetVolumeName()),
> > but
> > only to update an object when changes occured. I find it more
> > logical
> > to rather introduce an Update() method that retrieves and sets the
> > information by itself.
> Sounds reasonable.
Yup.
> > 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 :)
Adios...
Axel.
Other related posts:
