RE: Query related to lookup
RE: Query related to lookup
- Subject: RE: Query related to lookup
- From: Pratima Kudale <email@hidden>
- Date: Mon, 08 Apr 2013 11:06:18 -0700
- Acceptlanguage: en-US
- Thread-topic: Query related to lookup
Shantonu,
We are already supplying VNFS_NOCACHE flag to vnode_create(). But Ken and Me are facing a problem where we want to purge the name cache entry because file / folder is renamed / deleted remotely.
I was looking for entry point similar to dentry::revalidate from linux which will give us an opportunity to re-validate name cache entry. Currently, name cache implementation from Darwin kernel does not have any "time-to-live" duration assigned with it. Once you enter a vnode into name cache by calling cache_enter() , VFS won't ever call the file system driver to re-validate that name cache entry unless we remove the name cache entry via VNOP_RECLAIM / VNOP_INACTIVE.
Please let me know if you are aware of mechanism already supposed in VFS to achieve this.
Thanks,
Pratima
-----Original Message-----
From: Ken Hornstein [mailto:email@hidden]
Sent: Friday, March 29, 2013 6:37 AM
To: Shantonu Sen
Cc: Pratima Kudale; Pratima Kudale; email@hidden
Subject: Re: Query related to lookup
>You forgot the open source filesystems from Apple like msdosfs
Well ... that's only limited help, to be honest. Especially if you're writing a network filesystem (which I had to do, and the original author had to do as well). You have to manage your own memory pool and _THAT_ is hard, because the memory system is very confusing and has zero, zip, nada documentation. NFS is an example, but it's also confusing (and uses fun, mostly undocumented memory flags). I also used AFS as a reference, but that has it's own problems since the code is old and has tons of #ifdefs and is also designed to be portable, so you have a hard time figuring out exactly what you need and what you don't. I know, I know ... it's not like the lack of vfs interface documentation is a NEW problem. I'm just grumbling.
>> Specifically, the comments for the function "cache_purge()". Also,
>> as I understand it your file doesn't actually get added to the name
>> cache unless you call cache_enter(); you could simply not call
>> cache_enter() in your vnop_lookup routine (although I would
>> personally not recommend that). If you want to do that for _all_
>> cached vnodes in your filesystem, you could combine that with vnode_iterate().
>>
>
>That doesn't sound right. When a filesystem instantiates a vnode with
>vnode_create(), you pass options indicating whether a name cache entry
>should be created on your behalf. Filesystems can additional create or
>delete entries if it knows something VFS doesn't (like asynchronous
>invalidation, or negative cache entries). Most positive entries should
>be managed for you (especially during events like unlinks or renames)
Hm, really? Okay, let me look at this again ...
Alright, it's starting to come back to me now. If you find the vnode in your local hash, you're supposed to call cache_enter() to put it back in the name cache. But you're right in that normally when you call
vnode_create() the vnode is added to the name cache; my apologies for saying otherwise! Like you said, you can suppress this behavior (by using the flag VNFS_NOCACHE or VNFS_CANTCACHE). Although I'm not sure the positive entries are completely managed for you ... it seems that most renames end up calling cache_purge() at some point.
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden