[openbeosstorage] Re: DiskDevice API v2.1
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 20:06:15 +0200 CEST
"Axel D=F6rfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
>
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > > 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=3D3D3F
>
> 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 :-)
I see. However, that all doesn't help in general, since there is the
chance that directories have to be moved, and then problems can occur.
> 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).
Definitely.
> > > 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" :-))
I bet, this is insignificant in practice. A good cache is key, I'd say.
> 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.
It's current version at least misses important features. Attributes for
instance.
> At least we might learn about some goodies from them for the next
> incompatible BFS :)
Definitely. Let's shamelessly borrow as many good ideas as possible.
> > > 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=3D3D3D5Frefs 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.
Sure.
> > > 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).
Right. Actually, I meant the direct caller of the FS API functions,
i.e. the kernel side of the syscall.
> 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.
Not nice. :-(
> > 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=3D3D3F 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.
This was my bad. My short-lived proposal for BDiskSystem subclasses to
be created by the userland add-ons would indeed have caused a less
clear separation.
CU, Ingo
Other related posts:
