[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 04 Apr 2003 02:35:09 +0200 CEST
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > The main motivation is that it gives the partition code a chance to
> > declare what regions of unused space are valid for creating child
> > partitions.
> This might indeed be a good idea. Since the systems have some
> administrative overhead (the PTSs in the intel system), it could be
> quite convenient.
We will also need some kind of overhead or better a spare partition for
the partition meta data in R2. That includes things like how the
partitions have to be mapped during a move operation, but also
informations about the RAID setup or similar things.
It probably won't be possible to write this information down to an
existing file system.
We could then also place the boot loader in that extra partition, so
that the boot partition is free of any file system requirements (and
could itself be located on a RAID partition) :-)
> > I think I still like the idea of the BEmptySpace class (maybe
> > BPartitionableSpace would be better=3D3F), but I agree with moving
> > the
> > creation functions into the parent partition (i.e.
> > CreateChildPartition). Does that sound better=3D3F
> CreateChild() for consistency. Though BEmptySpace sounds suitable in
> the context of the DiskDevice API, I foresee a name clash when the
> indispensable Astronomer Kit is introduced in R2. ;-) So,
> BPartitionableSpace is better IMO.
Yes, I think I would like that better, too.
> > That's okay with me. I think we should have a way of finding out
> > which
> > partitions are locked and busy though (i.e. IsLocked()), or would
> > you
> > plan on Lock() being non-blocking=3D3F
> Yep, an IsLocked() makes sense. A non-blocking is preferable, I
> think.
Yep.
> > Why do you prefer the userland version=3D3F
> I reconsidered that, and I'm about to change my mind. :-)
> The reason, why I tended to like the userland version more, was that
> it
> is more lightweight -- a simple virtual function called vs. a
> syscall.
> But the API is not exactly performance critical and, I would be
> surprised, if thousand or more invocations per second would have any
> significant impact on modern hardware. So, even live checking of
> partition positions, while the user drags a slider or something like
> that, should be no problem at all.
>
> The big plus on the kernel version's side, is that using a
> partition's
> BDiskSystem doesn't require the respective userland add-on to be
> loaded. Only the kernel module, which needs to be loaded all the time
> anyway.
But keep in mind that in R1, kernel memory might not be pageable. So a
userland add-on could be thrown out of memory while a kernel add-on
might not. But I hope we'll get that right for R1 already.
Could you make a list of what kind of functionality the kernel module
should contain and how it should be accessed from userland=3F
> > Can do, but now you have to explain to me why you're so fond of
> > synchronous operation, because I still don't get it (and if you
> > told
> > me
> > back when we were working on the MIME update functions, it
> > obviously
> > didn't stick :-).
> I'm not *that* fond of synchronous operation. I just don't see the
> need
> to force the API user to have it done in another thread. E.g. if you
> have a worker thread, that couldn't proceed anyway until the disk is
> set up, you would just waste resources.
A thread should be a cheap resource in BeOS :-)
But of course, I agree with you - but I could also live with an
asynchronous version only, too :))
> > Sounds good, though should ValidateInitialize include an off=3D5Ft *
> > size
> > as
> > well=3D3F
> To return the size the system would actually use, so that the caller
> is
> e.g. able to warn the user, if space would be wasted when trying to
> initialize the partition with a FS with a smaller maximal size=3D3F
Dunno if that's necessary.
It would make more sense to set the minimum size the file system
supports there (if the provided size is smaller) :-)
Adios...
Axel.
Other related posts:
