[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Fri, 04 Apr 2003 20:29:44 +0200 CEST
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > I dunno - if it's easy to implement, then I would say why not. It
> > can
> > only add to the number of features :)
> We can still decide that, when we have a clearer picture of the
> kernel
> part. Even later, for I don't think, it would be that hard to switch
> from device- to partition-based locking or vice versa.
Right.
> > Okay, that seemed to be a stupid idea :)
> > But we should make sure that the user can see which tasks still
> > have
> > to be carried out
> We could add methods to BDiskDeviceRoster to provide support for
> that.
> The typical iteration methods (GetNextActiveJob(BDiskDeviceJob*),
> RewindActiveJobs()) and watching support (StartWatchingJobs(),
> StopWatchingJobs()). BDiskDeviceJob (or better name=3D3F) would feature
> methods for returning general information about the job, as well as
> its
> current progress.
Sounds good.
> >, 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.
> > 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=3D3F 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.
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. 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.
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).
> > Hm, maybe it was a bit too much of a good thing (a small kernel :-
> > ).
> :-)
> Also -- even, if I'm nitpicking here -- most of the functionality
> would
> be in modules, not in the kernel itself. Not that this means anything
> for the stability of the system. ;-)
Exactly. So, the ideal is, to move as much functionality as possible
out of the kernel space :)
But one doesn't have to exaggerate the realization of that idea either
:)
> > So I almost agree with you - the only problem I see is that both
> > modules (the kernel and the userland add-on) must be consistent;
> > the
> > kernel module must implement the features the userland add-on
> > promises.
> > That doesn't seem to be too much of a hassle, though.
> Exactly. Moreover, according to my current image, the userland add-
> ons
> would contain very little functionality, only the GUI code for
> editing
> the system-specific parameters. So, there is very little that needs
> to
> be consistent.
Very little, but important things :-)
> > 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=3D5Fref
> or an
> entry=3D5Fref (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=5Frefs 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.
With a successor to BFS, we will probably be able to reduce that
problem even more.
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=5Frefs in BeOS.
> All the BDiskSystem hooks should have counterparts in the FS API.
> There
> could also be one function that processes them all, like
> fs=3D5Fvalidate=3D5Foperation(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.
[...]
> 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.
> 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.
Adios...
Axel.
Other related posts:
