Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosstorage] || [Date Prev] [02-2003 Date Index] [Date Next] || [Thread Prev] [02-2003 Thread Index] [Thread Next]

[openbeosstorage] Re: Facing the End ;-)

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Sat, 15 Feb 2003 18:10:44 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > 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=3F ;-)

Yup :-))

[...]
> > 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=3F 
> That's definitely something users of other OSs would be damn 
> impressed 
> by. ;-)

And that's not even my primary concern ;-))
I don't think that partition resizing is done very often, but I think 
we have to provide a mechanism to make them safe against any crashes.
And when we've done that (and support defragmentation [and API to move 
files around]), doing the "online" version of it should be easy (yet 
very nice ;).

[...]
> > 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=5FGET=5FMEDIA=5FSTATUS ioctl(), if you mean that. It is 
> alright for a polling solution for removable media.

Well, AFAIK polling is the only way. All other notify mechanisms aren't 
reliable. We could have a kernel daemon that checks for media changes, 
and unmount devices if needed.
That way, we wouldn't have to care (almost) anywhere else in the 
kernel, and still provide notifications for higher levels.
The daemon would iterate over all mounted devices (using next=5Fdev()) 
and asks them if they had any media changes. Perhaps we can even have a 
more optimized internal API for that purpose.

[Implementing the new Device API in OpenTracker]
> > 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.

It certainly is :-)

Adios...
   Axel.







[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.