FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API v2.1

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> Somebody wrote:
> 
> > But anyway, it *is* a problem, and we will not be=20
> > able to solve it completely (and efficiently when=20
> > complete), due to the heavy usage of entry=3D3D5Frefs=20
> > in BeOS.
> 
> An offset in the in-memory data structure representing
> a volume/partition/whatever can efficiently and simply
> solve this problem assuming that you are simply going=20
> to move everything linearly.

I think the problem actually is for the cases of resizing and 
defragmenting, where things are being shuffled around (while still 
mounted :-). An entry_ref has a file descriptor in it, which maps to 
a vnode id in the vfs (right?). The vnode ids are assigned by the 
filesystem. I believe BFS bases the id off the address of the inode, 
which may get moved somewhere different during resize or 
defragmenting. In that case, any outstanding entry_refs to that inode 
are no longer valid.

> I assume entry_refs store the absolute position from
> the start of the disk and not the relative position
> from the start of the volume or this wouldn't be an
> issue, right?

Again, that's a filesystem dependent thing. BFS (and most 
filesystems, I believe) uses relative addresses. iso9660 and udf use 
absolute addresses (though udf 2.5 looks like it will have a sort of 
virtual addressing for inodes to help address this very problem, sort 
of similar to what Ingo mentioned previosly about ReiserFS and node 
ids, I believe).

-Tyler