[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 17:46:25 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > 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=3D20
> > 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=5Fref has a file descriptor in it, which maps to
> a vnode id in the vfs (right=3F). 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=5Frefs to that inode
> are no longer valid.
Yes, although an entry=5Fref only stores the inode number of the
directory, and the name of the file that it refers to. So it only
becomes an issue when a directory is moved around, not when files are
moved around.
That also looks like a good reason why the file cache should go through
the file system every time, and shouldn't directly access blocks on the
hard drive :-)
Adios...
Axel.
Other related posts:
