[openbeosstorage] Re: DiskDevice API v2.1
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 00:58:16 -0800
> 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
Other related posts:
