site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com I've been (probably foolishly) working on and off on porting an already- existing network filesystem to Darwin. I'm fairly far along, and I'm now at the point of handling data caching. Before anyone says anything ... yes, I've read Singh's book, and I've read the appropriate Apple documentation. They're both okay ... as starting points. They really don't go into the detail that I need at this point; what I've been using has been the NFS sources included in MacOS X as a guide. Fine, okay, that's what I expect when I get to this level, and I can deal with that. I am having a bit of uncertainty when it comes to the exact handling of UPLs. As I understand it (based on the NFS sources) a rough sequence of what I need to do so data caching is integrated properly with UBC is as follows: - Make sure the size of my vnode is set correctly with ubc_setsize() - Create some metadata to keep track of individual buffer status (dirty, whatever else) - When I need to "lock" a page within the UBC for a particular vnode, create a UPL with ubc_create_upl(). - When I need to read/write the data, I map it into the kernel's memory with ubc_upl_map() (I'm only doing this for reading right now). - After I'm done copying my data, I can remove the mapping with ubc_upl_unmap(). - When I'm done completely, I commit the UPL using ubc_upl_commit(). - I can then use cluster_copy_ubc_data() to copy the data to userspace (if I have the data already cached, I can just do this step). So the things I am not quite clear on ... - The semantics of PRECIOUS. Okay, the limited documentation on this says that the pages that are marked precious are assumed to be the only copy and that they always have to be returned to the memory manager when they need to be evicted, even when not dirty. The NFS code always makes sure that all pages that it is buffering are initially marked as precious. But then when an NFS buffer is released, if (for example) the buffer has just been used for reading then the precious flag is cleared by the UPL_COMMIT_CLEAR_PRECIOUS flag. To me this means that if the VM system wants to evict a page due to memory pressure it can do so without letting NFS know via a VNOP_PAGEOUT() call. It may be that this doesn't matter for NFS; from what I see if nfs can't copy data from the UBC using cluster_copy_ubc_data() it just starts transferring it from the server. So, am I right in my understanding that if I mark a page as precious, I will always get a VNOP_PAGEOUT() for it? Does marking a page as precious have any other side effects that I should be aware of? I see from the kernel sources that in most places there is a test for a page being dirty or precious at the same time, so I am guessing their semantics are close. - What exactly does UPL_COMMIT_INACTIVATE do? The documentation in ubc_subr.c says "Clear each pages reference bit; the page will not be accessed". The NFS code does this for all released buffers. I know this clears the "reference" flag in the page, but I'm not clear on what exactly this _means_; should I always use this flag when I commit a UPL? - If I get notification from the fileserver that pages I have cached are no longer valid, how should I tell the UBC that? (Presume that we're already doing the appropriate locking so no dirty client-side data will be lost). ubc_msync() with UBC_INVALIDATE? Thanks for any help you can give me, --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com