Re: DiskDevice API v2.1

Tyler Dauwalder <tyler-cyCl/[email protected]> 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.