Re: Arla on FreeBSD

Robert Watson <[email protected]>
Newsgroups gmane.os.freebsd.devel.file-systems,gmane.comp.file-systems.arla.general
Message-ID <[email protected]>
On Thu, 15 Feb 2007, Tomas Olsson wrote:

>> Also, you could look at file handle API, that would save you of path 
>> lookups after the vnode is looked up first time (look around for vfs_vptofh 
>> and vfs_fhtovp ops). This API is used by NFS server, so it shall work :).
>>
> That's an idea. We used that before in another context, but then we ran into 
> trouble with too many OSes so we dropped it.  Depends on how much code one 
> can share.

It has been ages since I looked at the xfs/nnpfs internals, but I thought it 
already used file handles to identify cache files to the kernel?  I seem to 
recall several of our fh*() system calls were added by Assar specifically in 
support of Arla work.

With regard to cache files -- historically (i.e., last time I looked closely), 
there was a one-to-one mapping between cache files and files in the Arla 
working set, and all files were transfered "whole" into the local cache. 
This was in contrast to AFS's chunking behavior.  I assume the cache file 
changes to support "lines" in the cache are in support of adding chunking to 
Arla.  Is it the case that one file visible in /afs may now be backed by pages 
coming from different cache files?  How does this interact with the vnode 
pager?  I assume you actually end up with two pagers -- one for the file as 
visible in /afs, and then satisfy the pager's VOP requests by forwarding them 
to the right one of the cache vnodes?  I trust you don't mmap the cache vnode, 
which would lead to cache consistency issues between any mappings of the /afs 
vnode vs the cache vnode?

Any chance we could attract you to BSDCan to meet in person to discuss this? 
:-)

Thanks,

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.