[openbeosstorage] Re: DiskDevice API v2.1
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 04 Apr 2003 22:15:57 +0200 CEST
"Axel D=F6rfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
[...]
> > >, which are already done, etc. - and that data must
> > > survive a crash as well.
> > Your meta data partition sounds like a very good solution to that.
>
> Yes, we just need to have access to that data from userland, too.
> It seems to me that the kernel API needed to provide all that
> features
> is rather huge. Not that this would be a major problem.
It's quite natural that the API required grows with the number of
features. And thinking of all the features you have in mind, it
wouldn't surprise me, if the outcome is a rather big API. ;-)
> > > No, it wouldn't be the same as in R5 - the kernel couldn't
> > > recognize
> > > partitions at all.
> > A bit of partition support for booting must be in the kernel,
> > anyway.
> > Or do I miss something=3D3D3F It would also be nice, if booting from
> > logical
> > partitions was supported.
>
> Exactly, the R5 kernel knew about partitions at boot time, but then
> forgot about them immediately afterwards, and only relied on
> userspace
> add-ons later. Changing that was my primary concern with the new
> architecture :-)
> But of course, that wouldn't require write support per se - that's
> why
> I had the idea to move that out of the kernel, but then, it really
> doesn't make that much sense.
True.
> Anyway, booting from logical partitions would be easily possible, as
> long as the boot loader supports it. And it should be pretty easy to
> add that support, since the boot loader almost haven't got anything
> to
> know about partitions anyway :-)
>
> The 2nd stage boot loader (the real work) would need to have that
> support, too, of course.
Yes, that one I was thinking of.
> Perhaps it could already load our modules, but
> that might require that only a very small amount of functions are
> available to them.
> The whole boot loader thing still needs to be specified exactly.
Yes.
> On PPC, it looks like it's standard to have an extra partitions for
> the
> boot images. That partition is of a format the firmware understands
> (like AmigaFFS for the Pegasos :).
> When we have specified the layout, I will also write a module to
> support the Amiga partitioning scheme, since it's probably going to
> be
> used on the Pegasos as well, AFAICT. And I still have some hard
> drives
> to test it lying around. Maybe we even require an Amiga FFS
> compatible
> fs add-on for the Pegasos support, but that should be very easy to do
> (though it's additional work).
Cool. :-)
[...]
> > > Or we could introduce the requirement to unmount those partitions
> > > first.
> > I wonder anyway, how it can be done, while the FS is mounted. I
> > mean,
> > even node IDs may change during resizing. I don't know the inner
> > workings of the VFS, but at least applications holding a node=3D
> > 3D5Fref
> > or an
> > entry=3D3D5Fref (among them the Tracker, I suppose) may end up being
> > very
> > confused.
>
> That problem will also be introduced by defragmentation (which we
> also
> have to support). entry=3D5Frefs might not stay valid, there is no way
> around that (with BFS).
> But this problem shouldn't be too big, since files (and their data)
> are
> much more likely to be moved around than directories.
Is that a property of BFS, i.e. are directory nodes preferrably created
at the beginning of the partition=3F
> With a successor to BFS, we will probably be able to reduce that
> problem even more.
BTW, ReiserFS doesn't have a problem with that, since it doesn't code
the physical location into the node ID, but the key of the object (used
to locate the object in the tree), and thus the node ID won't change
when the file/dir is relocated.
> But anyway, it *is* a problem, and we will not be able to solve it
> completely (and efficiently when complete), due to the heavy usage of
> entry=3D5Frefs in BeOS.
That's bad. :-(
> > All the BDiskSystem hooks should have counterparts in the FS API.
> > There
> > could also be one function that processes them all, like
> > fs=3D3D5Fvalidate=3D3D5Foperation(uint32 operation, void *parameters).
>
> Yeah, that would also work, although it probably wouldn't be too easy
> to check the arguments in that case. The FS add-on shouldn't be
> bothered with this, at least.
Yes, the caller would have to make sure, that the parameters are valid.
> [...]
> > If we really limit the userland add-ons to provide only the GUI for
> > the
> > system-specific parameters -- for intel partitions that would be
> > the
> > partition type and the `active' flag -- then the add-on won't be
> > needed
> > before the parameters are actually going to be displayed/edited.
>
> That's what I meant - I want that this usage pattern is mirrored in
> the
> actual implementation.
Mmh, I don't quite see the problem, or rather the point where you want
more separation. It's actually quite simple: Each method returning a
BDiskScannerParameterEditor* (three in BPartition) needs to load an add
-on. Would you prefer to explicity load/unload the add-ons
(BDiskDeviceRoster::{Load,Unload}AddOn()) and get the parameter editors
from them directly=3F This is less convenient at the least, aside from
that I don't see the benefit.
> > We could even dynamically load/unload the add-ons. This means the
> > add
> > -
> > on has to be reloaded with every request of a parameter editor,
> > but,
> > since those add-ons won't be that huge, this will be reasonably
> > fast
> > (not that quick for laptop users, when the HD is turned off at that
> > moment, though).
>
> That would probably be overkill, but since we have mmap, and use it :
> -)
> that probably won't require a hard disk access every time.
Ah, didn't think of that. :-)
CU, Ingo
Other related posts:
