Re: DiskDevice API v2.1

"Axel D=F6rfler"  <[email protected]> wrote:
> 
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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