[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 16:48:22 +0200 CEST
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > 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. ;-)
Yeah, that might happen :-)
[...]
> > 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=3D3F
No, it's just that there are more files than directories, and the
directories are likely to be created before the files in them, so there
is probably less to move around :-)
Normally, directory entries are written every 8 allocation groups; for
each subdirectory, the next chunk will be used. OTOH files are going
into the same allocation group than their parent directory, if
possible.
That allocation policy is for sure not optimally, but it's so much
better than nothing (i.e. like NTFS).
> > 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.
Oh, that's what I meant with "not efficiently" :-))
But you are probably right, it looks like a good idea for solving those
problems in a BFS successor, too. Maybe we can even use ReiserFS as our
main FS (optionally), though I am not that familiar with its features
yet.
At least we might learn about some goodies from them for the next
incompatible BFS :)
> > 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=3D3D5Frefs in BeOS.
> That's bad. :-(
Yep, we will have to see how well it'll work in real life then. I don't
think it'll be too bad.
> > 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.
Not directly, everything must be checked in the kernel itself - it
shouldn't be that easy to kill the kernel with invalid parameters
(intentionally or not).
For example, you can kill BeOS using ioctl() with a two line program -
and we will inherit that "feature" with all original BeOS drivers. Our
own drivers will have to check the parameters correctly.
> > 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=3D3F This is less convenient at the least, aside
> from
> that I don't see the benefit.
Oh, I wasn't aware that it already is that separated :-)
Sorry! I think the way it is now is perfectly okay.
Adios...
Axel.
Other related posts:
